Na wynos: Prowadzący Eric Kavanagh omówił debugowanie i profilowanie bazy danych z Dr. Robin Bloor, Dez Blanchfield i IDERA Bert Scalzo.
Obecnie nie jesteś zalogowany. Zaloguj się lub zarejestruj, aby zobaczyć wideo.
Eric Kavanagh: Okay, panie i panowie, w środę jest godzina 4:00 czasu wschodniego, i to oczywiście oznacza.
Robin Bloor: Nie słyszę cię, Eric.
Eric Kavanagh: Byłem tam kilka dni temu, więc nie jesteś sam. Ale dzisiejszy temat jest naprawdę interesujący. Jest to coś, co chcesz mieć pewność, że dzieje się w tle w Twojej firmie, chyba że jesteś osobą, która to robi, w takim przypadku chcesz upewnić się, że robisz to poprawnie. Ponieważ mówili o debugowaniu. Nikt nie lubi błędów, nikt nie lubi, gdy oprogramowanie przestaje działać - ludzie się denerwują, użytkownicy stają się nieprzyjaźni. To nie jest dobrze. Zamierzaliśmy więc mówić o „szybkiej reakcji: debugowanie bazy danych i profilowanie na ratunek”.
Naprawdę jest twoje miejsce, uderz mnie, @eric_kavanagh, oczywiście.
Ten rok jest gorący. Debugowanie będzie gorące, bez względu na wszystko. To naprawdę będzie jeden z tych problemów, który nigdy nie zniknie, bez względu na to, jak dobrze sobie z tym poradzimy, zawsze będą problemy, więc kluczem jest to, jak dotrzeć do miejsca, w którym można szybko rozwiązać te problemy? Idealnie jest, jeśli masz świetnych programistów, świetne środowiska, w których niewiele się dzieje, ale jak mówi stare powiedzenie: „Wypadki zdarzają się w najlepszych rodzinach”. To samo dotyczy organizacji. Tak więc, takie rzeczy się zdarzają, to się wydarzy, pytanie brzmi: jakie będzie twoje rozwiązanie, aby sobie z tym poradzić i rozwiązać te problemy?
Słuchajcie doktora Robina Bloora, potem naszego własnego Deza Blanchfielda z dołu i oczywiście naszego dobrego przyjaciela, Berta Scalzo, z IDERA. I faktycznie, zamierzam oddać klucze Robin Bloor, zabierz je. Podłoga jest twoja.
Robin Bloor: DOBRZE. To ciekawy temat. Myślałem, że ponieważ Dez prawdopodobnie będzie kontynuował aktualne techniki i historie wojenne dotyczące debugowania, pomyślałem, że po prostu przeprowadzę dyskusję w tle, aby uzyskać pełny obraz tego, co się dzieje. Robiłem to przez długi czas i kiedyś byłem programistą, więc tak jest i prawie kusiło mnie to, że zacząłem lirować na temat otwartego oprogramowania, ale pomyślałem, że zostawię to komuś innemu.
Oto lista znanych błędów, a większość z nich trafia na najwyższą listę anybodys, w zasadzie wszystkie oprócz dwóch ostatnich kosztują co najmniej 100 milionów dolarów. Pierwszym z nich był Mars Climate Orbiter, zagubił się w przestrzeni kosmicznej i to z powodu problemu z kodowaniem, w którym ludzie mylili jednostki metryczne z (śmiech) stopami i calami. W Ariane Five Flight 501 wystąpiło niedopasowanie między uruchomionym silnikiem a komputerami, które miały uruchamiać rakietę po jej uruchomieniu. Wiele awarii komputera, wybuchająca rakieta, najważniejsze wiadomości. Radziecki gazociąg w 1982 roku, o którym mówi się, że jest największą eksplozją w historii planety; Nie jestem pewien, czy tak jest. Rosjanie ukradli oprogramowanie do automatycznej kontroli, a CIA zdało sobie sprawę, że zamierzają to zrobić i włożyło w to błędy, a Sowieci wdrożyli je bez testowania. Więc wysadziłem rurociąg, pomyślałem, że to zabawne.
Robak Morris był eksperymentem kodowania, który nagle stał się drapieżnym robakiem, który krążył wokół każdego człowieka - najwyraźniej spowodował szkody o wartości 100 milionów dolarów; to jest oczywiście szacunek. Intel popełnił słynny błąd z układem matematycznym - instrukcją matematyczną dotyczącą układu Pentium w 1993 roku - która miała kosztować ponad 100 milionów dolarów. Program Apple Maps to prawdopodobnie najgorsze i najbardziej katastrofalne uruchomienie wszystkiego, co Apple kiedykolwiek zrobił. Ludzie, którzy próbowali go użyć, to znaczy, że ktoś jechał wzdłuż 101, i odkryli, że Apple Map mówi, że są w środku Zatoki San Francisco. Ludzie zaczęli nazywać aplikację Apple Maps nazwą iLost. - Nasz najdłuższy przestój w 1990 roku - jest po prostu interesujący z punktu widzenia kosztu czegoś takiego - AT&T były dostępne przez około dziewięć godzin i kosztowały około 60 milionów dolarów za połączenia międzystrefowe.
Byłem w brytyjskiej firmie ubezpieczeniowej, a baza danych wdrożyła nową wersję bazy danych i zaczęła wymazywać dane. I pamiętam to bardzo dobrze, ponieważ zostałem później wezwany do wzięcia udziału w wyborze bazy danych z tego powodu. I to było bardzo interesujące, że wzięli nową wersję bazy danych i mieli szereg testów, które zrobili dla nowych wersji bazy danych, które przeszły wszystkie testy. Znalazł naprawdę niejasny sposób czyszczenia danych.
W każdym razie to tyle. Myślałem, że mówię o niedopasowaniu impedancji i wydanym SQL. Interesujące jest to, że relacyjne bazy danych przechowują dane w tabelach, a kodery mają tendencję do manipulowania danymi w strukturach obiektowych, które tak naprawdę nie bardzo dobrze mapują do tabel. Z tego powodu otrzymujesz coś, co nazywa się niedopasowaniem impedancji i ktoś musi sobie z tym poradzić w taki czy inny sposób. Ale to, co faktycznie się dzieje, ponieważ jeden model, model koderów i baza danych inny model, nie są specjalnie dostosowane. Dostajesz błędy, które po prostu by się nie zdarzyły, gdyby przemysł zbudował rzeczy, które działają razem, co moim zdaniem jest przezabawne. Zasadniczo, po stronie programistów, kiedy dostajesz hierarchie, mogą to być typy, zestawy wyników, może to być słaba zdolność API, może być wiele rzeczy, które po prostu wyrzucają rzeczy pod względem interakcji z bazą danych. Ale to, co dla mnie najważniejsze, naprawdę interesujące; zawsze mnie dziwiło, że masz barierę SQL, która jest również impedancją w taki sposób, że kodery i baza danych współpracują ze sobą. Tak więc SQL ma rozpoznawanie danych, co jest w porządku i ma DML dla select, project i join, co jest w porządku. Dzięki temu możesz rzucić wiele możliwości w zakresie pobierania danych z bazy danych. Ale ma bardzo mało języka matematycznego do robienia rzeczy. Ma trochę tego i tamtego i ma bardzo mało rzeczy opartych na czasie. Z tego powodu SQL jest, jeśli chcesz, niedoskonałym sposobem na uzyskanie danych. Więc faceci z bazy danych zbudowali procedury składowane, aby żyć w bazie danych, a powodem ich przechowywania było to, że tak naprawdę nie chciałeś rzucać danymi tam iz powrotem do programu.
Ponieważ niektóre funkcje były wyjątkowo specyficzne dla danych, więc nie chodziło tylko o integralność referencyjną i usuwanie kaskadowe itp., Baza danych zajmowała się nagłym umieszczaniem funkcji w bazie danych, co oznaczało oczywiście, że funkcjonalność aplikację można podzielić na koder i samą bazę danych. To sprawiło, że praca nad implementacją niektórych funkcji była naprawdę trudna, a zatem bardziej podatna na błędy. Jest to więc jedna strona gry bazodanowej, ponieważ oznacza to, że wdrożyłeś wiele implementacji, na przykład, że byłem zaangażowany w relacyjne bazy danych. Naprawdę strasznie dużo kodu znajduje się w procedurach przechowywanych, które są obsługiwane oddzielnie od kodu, który siedzi w aplikacjach. I wydaje się, że to bardzo dziwna rzecz, która powinna być dość mądra w robieniu różnych rzeczy.
Myślałem, że mówię także o wydajności bazy danych, ponieważ błędy wydajności są często uważane za błędy, ale w zasadzie możesz mieć wąskie gardło w procesorze, w pamięci, na dysku, w sieci i możesz mieć problemy z wydajnością z powodu blokowania. Pomysł polegałby na tym, że programista tak naprawdę nie musiał martwić się wydajnością, a baza danych faktycznie działała dość dobrze. Ma być zaprojektowany tak, aby koder nie musiał wiedzieć. Jednak dostajesz zły projekt bazy danych, dostajesz zły projekt programu, dostajesz współbieżność w mieszaniu obciążeń, co może również prowadzić do problemów z wydajnością. Dostajesz równoważenie obciążenia, dostajesz planowanie pojemności, wzrost danych - może to spowodować zatrzymanie lub spowolnienie bazy danych. To ciekawe, że gdy bazy danych są prawie pełne, zwalniają. I możesz mieć problem z warstwami danych w zakresie replikacji i potrzeby replikacji oraz potrzeby tworzenia kopii zapasowych i odzyskiwania. Tak czy inaczej, to ogólny przegląd.
Jedyne, co chciałbym powiedzieć, to to, że debugowanie bazy danych może być tak samo uciążliwe i nietrywialne - i mówię to, ponieważ zrobiłem dużo tego - i często odkryjesz, że są to wszystkie sytuacje podczas debugowania, których kiedykolwiek doświadczyłem to pierwsza rzecz, jaką kiedykolwiek zobaczysz, to bałagan. I musisz spróbować przejść od bałaganu do ustalenia, jak powstał bałagan. I często, gdy patrzysz na problem z bazą danych, patrzysz tylko na uszkodzone dane i myślisz: „Jak do cholery to się stało?”
W każdym razie przekażę Dezowi, który prawdopodobnie powie więcej mądrości niż się wydałem. Nie wiem, jak podać ci piłkę, Dez.
Eric Kavanagh: Podam to, stójcie, poczekajcie.
Zautomatyzowany głos: Linie uczestników zostały wyciszone.
Eric Kavanagh: W porządku, poczekaj sekundę, pozwól mi dać piłkę Dezowi.
Dez Blanchfield: Dziękuję, Eric. Tak, doktorze Robin Bloor, naprawdę masz rację: jest to temat, dożywotni błąd, jeśli wybaczysz kalambura, przepraszam, że nie mogłem się powstrzymać. Mam nadzieję, że zobaczysz tam mój pierwszy ekran, przepraszam za problem z rozmiarem czcionki u góry. Tematem błędów jest wykład całodzienny, w wielu przypadkach z mojego doświadczenia. Jest to tak szeroki i szeroki temat, więc skupię się na dwóch kluczowych obszarach, a konkretnie na koncepcji tego, co uważamy za błąd, ale na problemie programistycznym. Myślę, że w dzisiejszych czasach wprowadzenie błędu jako takiego jest zazwyczaj wychwytywane przez zintegrowane środowiska programistyczne, chociaż mogą to być długotrwałe błędy. Ale często jest to bardziej przypadek profilowania kodu i możliwe jest napisanie kodu, który działa, to powinien być błąd. Tak więc, mój slajd tytułowy, miałem kopię tego w bardzo wysokiej rozdzielczości A3, ale niestety został zniszczony w wyniku przeprowadzki. Ale jest to odręczna notatka na arkuszu programowania z około 1945 r., Gdzie podobno niektórzy ludzie z Harvard University w USA, ich druga wersja maszyny o nazwie Mark II. Debugowali jakiś problem we wspólnym języku, ale próbowali znaleźć usterkę i okazało się, że pojawiło się coś nieco innego niż sprzęt i rzekomo problem z oprogramowaniem.
Tak więc mit miejski jest taki, że około 9 wrześniath, 1945 zespół z Uniwersytetu Harvarda rozbierał maszynę, natrafił na coś, co nazwali „przekaźnikiem siedemdziesiąt” - w tamtych czasach programowanie odbywało się w sensie fizycznym, nawijałeś kod na tablicę i tak skutecznie programowałeś maszyna - i znaleźli ten przekaźnik numer siedemdziesiąt, coś było z nim nie tak i okazuje się, że faktycznie pojawił się termin „pluskwa”, ponieważ dosłownie była to ćma - podobno ćma była wciśnięta między kawałek drutu miedzianego z jednego miejsca na drugie. I historia głosi, że legendarny Grace Hopper jako ten podpis, na slajd tytułowy, „pierwszy rzeczywisty przypadek znalezienia błędu” cytuje bez cytatu.
Ale jak Robin podkreślił wcześniej w swoim pierwszym slajdzie, koncepcja błędu sięga daleko wstecz, jak możemy sobie wyobrazić, że ludzie wykonują obliczenia, takie pojęcia jak łatka. Termin „łatka” pochodzi od faktycznego kawałka taśmy naklejonej na otwór na karcie dziurkacza. Ale w tym wszystkim chodzi o to, że termin „debugowanie” wywodzi się z koncepcji znalezienia błędu w maszynie fizycznej.Od tamtej pory używamy tej terminologii, próbując poradzić sobie z problemami, albo nie tyle jak problemy z kodowaniem w programie, który się nie kompiluje, ale jako program, który nie działa dobrze. I nie został specjalnie wyprofilowany, po prostu znajduj takie rzeczy, jak niekończące się pętle, które nigdzie nie idą.
Ale mamy też scenariusz i pomyślałem, że umieściłem kilka zabawnych slajdów, zanim przedstawiłem nieco więcej szczegółów. Oto klasyczny rysunek o nazwie XKCD w Internecie, a rysownik ma całkiem zabawne poglądy na temat świata. A te o dziecku zwanym „Little Bobby Stoły” i podobno jego rodzice nazwali tego młodego chłopca Robertem); DROP TABLE Studenci; - i nazywa się: „Cześć, to szkoła twojego syna ma problemy z komputerem”, a rodzic odpowiada: „Och, kochanie, czy coś zepsuł?”. A nauczyciel mówi: „Cóż, w pewnym sensie ”, a nauczyciel pyta:„ czy naprawdę nazywałeś swojego syna Roberta); DROP TABLE Studenci; -? ”A rodzic mówi:„ Och tak, nazywamy go małymi stolikami Bobby'ego ”. W każdym razie dalej mówią, że stracili już zapisy z lat studenckich, mam nadzieję, że jesteś szczęśliwy. Odpowiedź brzmi: „Cóż, powinieneś wyczyścić i zdezynfekować dane wejściowe do bazy danych”. I używam tego wielokrotnie, aby porozmawiać o niektórych problemach ze znalezieniem rzeczy w kodzie, że często kod również nie patrzy na dane .
Kolejny zabawny, nie wiem, czy to prawda, czy nie - podejrzewam, że to podróbka - ale znowu dotyka mojej śmiesznej kości. Ktoś zmienia tablicę rejestracyjną z przodu samochodu, na podobne stwierdzenie, które powoduje, że bazy danych upuszczają fotoradary i tak dalej, przechwytując tablice rejestracyjne samochodów. I zawsze nazywam to tym, że wątpię, aby jakikolwiek programista oczekiwał trafienia i uruchomienia ich kodu przez rzeczywisty pojazd silnikowy, ale nigdy nie lekceważy tego - moc gniewnego maniaka.
(Śmiech)
Ale to prowadzi mnie do mojego kluczowego punktu, i myślę, że dawno temu moglibyśmy debugować i profilować kod jako zwykli śmiertelnicy. Ale jestem bardzo przekonany, że ten czas minął, i z mojego doświadczenia, anegdotycznie, po raz pierwszy - i to strasznie mnie starzeje, jestem pewien; Robin, możesz naśmiewać się ze mnie za to - ale historycznie pochodzę z 14-letniej rodziny, która wędruje na końcu miasta i puka do drzwi centrum danych o nazwie „Data Com” w Nowej Zelandii i pyta, czy Mógłbym zarobić kieszonkowe w szkole, dowożąc spóźniony autobus do domu, około 25 km codziennych dojazdów do pracy, wkładając papier i taśmy do napędów taśmowych, i po prostu będąc ogólnym administratorem. I co ciekawe, dali mi pracę. Ale z czasem udało mi się dostać do personelu i znaleźć programistów i zdałem sobie sprawę, że uwielbiam kodować i przeszedłem proces uruchamiania skryptów i zadań wsadowych, które na koniec są kodami. Musisz pisać skrypty i zadania wsadowe, które wyglądają jak miniprogramy, a następnie przejść przez cały proces ręcznego pisania kodu na terminalu 3270.
W rzeczywistości, moje pierwsze doświadczenie dotyczyło terminala teletekstowego, który w rzeczywistości był fizycznie 132-kolumnowy. Zasadniczo pomyśl o bardzo starej maszynie do pisania z przewijanym przez nią papierem, ponieważ nie mieli rurki CRT. Debugowanie kodu na ten temat było bardzo nietrywialne, więc zwykle pisałeś cały kod ręcznie, a następnie działałeś jak maszynistka, starając się nie dopuścić do błędów, aby się do niego wślizgnąć, ponieważ jego frustracja jest bardzo frustrująca edytor jednowierszowy, który przechodzi do określonej linii, a następnie do linii, a następnie wpisuje ją z powrotem. Ale kiedyś tak pisaliśmy kod i tak debugowaliśmy i byliśmy w tym bardzo, bardzo dobrzy. W rzeczywistości zmusiło nas to do posiadania bardzo dobrych technik programowania, ponieważ naprawienie go było naprawdę trudne. Ale podróż wtedy przeszła - i wszyscy to znali - przeszła od terminalu 3270 w moim świecie do Digital Equipment VT220, gdzie można było zobaczyć rzeczy na ekranie, ale znowu robiłeś to samo, co zrobiłeś na taśmie papierowej w rodzaju formatu ed tylko na CRT, ale można było łatwiej usunąć i nie było tego dźwięku „dit dit dit dit”.
A potem wiesz, terminale Wyse - jak Wyse 150, prawdopodobnie mój ulubiony interfejs do komputera - i potem PC, a potem Mac, a teraz nowoczesne GUI i identyfikatory oparte na sieci. Oraz szereg programów dzięki temu, programowanie w jednym i asemblerze oraz PILOT i Logo i Lisp i Fortran i Pascal oraz języki, które mogą wywoływać u ludzi dreszcze. Ale są to języki, które zmusiły cię do napisania dobrego kodu; nie pozwoliły ci uniknąć złych praktyk. C, C ++, Java, Ruby, Python - i przechodzimy dalej na tym etapie programowania, stajemy się bardziej podobni do skryptów, zbliżamy się coraz bardziej do Structured Query Language i języków takich jak PHP, które są faktycznie używane do wywoływania SQL. Chodzi mi o to, że pochodząc z mojego doświadczenia, byłem samoukiem na wiele sposobów, a te, które pomogły mi w nauce, nauczyły mnie bardzo dobrych praktyk programowania i bardzo dobrych praktyk dotyczących projektowania i procesów, aby upewnić się, że nie wprowadziłem błędów kod.
Metody programowania w dzisiejszych czasach, takie jak na przykład Structured Query Language, SQL, to bardzo potężny, prosty język zapytań. Ale przekształciliśmy go w język programowania i nie sądzę, aby SQL był kiedykolwiek zaprojektowany jako nowoczesny język programowania, ale zmieniliśmy go, aby tak się stało. I to wprowadza całą masę problemów, ponieważ kiedy myślimy o nich z dwóch punktów widzenia: z punktu widzenia kodowania i z punktu widzenia DBA. Bardzo łatwo jest go wprowadzić i wprowadzić błędy w takich rzeczach, jak słabe techniki programowania, leniwe wysiłki w pisaniu kodu, brak doświadczenia, klasyczne wkurzanie, które mam na przykład, gdy ludzie SQL skaczą po Google i szukają czegoś i znajdują stronę dostałem przykład i robię kopię i wklejanie istniejącego kodu. A następnie powielanie złego kodowania, nadużyć i wprowadzanie go do produkcji, ponieważ po prostu daje im oczekiwane rezultaty. Masz inne wyzwania, na przykład, w tych dniach wszyscy pędzili w kierunku tego, co nazywamy wyścigiem do zera: staramy się robić wszystko tak tanio i tak szybko, że mamy scenariusz, w którym nie zatrudniamy pracowników o niższych wynagrodzeniach. Nie mam na myśli tego w nieuczciwy sposób, ale nie zatrudniałem ekspertów do każdej możliwej pracy. Dawno, dawno temu coś związanego z komputerami było nauką o rakietach; był zaangażowany w rzeczy, które wybuchły i były bardzo głośne, lub w kosmos, albo inżynierowie byli wysoko wykwalifikowanymi mężczyznami i kobietami, którzy zdobyli stopnie naukowe i mieli rygorystyczne wykształcenie, które powstrzymywało ich od robienia szalonych rzeczy.
W dzisiejszych czasach wielu ludzi zajmuje się tworzeniem i projektowaniem oraz bazami danych, którzy nie mieli lat doświadczenia, nie mieli koniecznie takiego samego szkolenia lub wsparcia. I tak kończysz się scenariuszem tradycyjnego amatora kontra eksperta. I jest taka słynna linia, nie pamiętam, kto stworzył cytat, linia brzmi: „Jeśli uważasz, że kosztowne zatrudnienie eksperta do wykonania pracy, zaczekaj, aż zatrudnisz kilku amatorów, którzy stwarzają problem, i musisz wyczyść to. ”Tak więc SQL ma ten problem i jest bardzo, bardzo łatwy do nauczenia, bardzo łatwy w użyciu. Moim zdaniem nie jest to jednak idealny język programowania. Łatwo jest robić rzeczy takie jak zrobić wybraną gwiazdę z dowolnego miejsca i przeciągnąć to wszystko do języka programowania, który jest dla ciebie wygodniejszy, jak PHP, Ruby lub Python, i używać języka programowania, który znasz natywnie, do manipulacji danymi, zamiast wykonywać bardziej złożone zapytania w SQL. I często to widzimy, a potem ludzie zastanawiają się, dlaczego baza danych działa wolno; to dlatego, że milion ludzi próbuje kupić bilet z internetowego systemu biletowego, w którym wybiera wybraną gwiazdę z dowolnego miejsca.
To naprawdę ekstremalny przykład, ale rozumiesz o tym wszystkim. Tak więc, aby naprawdę uderzyć ten punkt do domu, oto przykład, który dużo noszę. Jestem wielkim fanem matematyki, uwielbiam teorię chaosu, uwielbiam zestawy Mandelbrota. Po prawej stronie znajduje się wersja zestawu Mandelbrot, którą z pewnością wszyscy znali. A po lewej stronie znajduje się fragment SQL, który faktycznie to renderuje. Teraz, za każdym razem, gdy gdzieś umieszczam to na ekranie, słyszę: „O mój boże, ktoś wyrenderował serię Mandelbrot za pomocą SQL, mówisz poważnie? To szaleństwo! ”Cóż, chodzi o to, aby zilustrować to, co właśnie tam nakreśliłem, i tak, w rzeczywistości można teraz zaprogramować prawie wszystko w SQL; jest to bardzo mocno rozwinięty, potężny, nowoczesny język programowania. Kiedyś był to język zapytań, był zaprojektowany tak, aby po prostu uzyskać dane. Więc teraz mamy bardzo skomplikowane konstrukcje i procedury składowane, mamy metodologię programowania stosowaną do języka, a więc bardzo łatwo jest to z powodu złej praktyki programowania, braku doświadczenia, wycinania i wklejania kodu, nisko opłacanego personelu próbującego być wysoko opłacanym personelem, ludźmi udającymi, że wiedzą, ale muszą się uczyć w pracy.
Cały szereg rzeczy, w których profilowanie kodu i to, co nazywamy debugowaniem, to nie tyle znajdowanie błędów, które zatrzymują programy, ale błędy, które po prostu szkodzą systemowi i źle skonstruowanemu kodowi. Kiedy patrzysz teraz na ten ekran i myślisz, że to jest po prostu słodkie i myślisz: „Wow, co za świetna grafika, uwielbiam to robić”. Ale wyobraź sobie, że działa na jakiejś logice biznesowej. Wygląda to całkiem schludnie, ale mówi matematyczną teorię chaosu, ale jeśli pomyślisz o tym, do czego może być potencjalnie wykorzystana w jakiejś logice biznesowej, możesz uzyskać obraz bardzo szybko. I naprawdę to zilustrować - i przepraszam, że kolory są odwrócone, to ma być czarne tło i zielony, aby być zielonym ekranem, ale nadal możesz to przeczytać.
Poszedłem i rzuciłem okiem na przykład tego, co możesz potencjalnie zrobić, jeśli byłbyś naprawdę szalony i nie miałeś żadnego doświadczenia, pochodziłem z innego środowiska programowania i zastosowałem C ++ do SQL, aby naprawdę zilustrować mój punkt widzenia, zanim Przekazuję naszemu uczonemu gościowi z IDERA. Jest to zapytanie strukturalne napisane jak C ++, ale zakodowane w SQL. I faktycznie działa, ale działa przez około trzy do pięciu minut. I wycofuje pozornie jedną linię danych z wielu baz danych, wiele połączeń.
Ponownie chodzi o to, że jeśli nie masz odpowiednich narzędzi, jeśli nie masz odpowiednich platform i środowisk, aby móc złapać te rzeczy, a one wchodzą do produkcji, a następnie masz 100 000 osób uderzających w system co dzień, godzina, minuta, bardzo niedługo skończysz w Czarnobylu, w którym wielkie żelazo zaczyna się topić i zakopywać w jądrze planety, ponieważ ten fragment kodu nigdy nie powinien wejść do produkcji. Wasze systemy i narzędzia, przepraszam, powinny to odebrać, zanim dotrze gdziekolwiek w pobliżu - nawet podczas procesu testowego, nawet przez UAT i integrację systemów, ten fragment kodu powinien zostać pobrany i wyróżniony, a ktoś powinien zostać odłożony na bok i mówiąc: „Spójrz, to naprawdę ładny kod, ale pozwalamy uzyskać DBA, które pomoże ci poprawnie zbudować to ustrukturyzowane zapytanie, bo szczerze mówiąc, to po prostu paskudne.” I tam adresy URL, możesz przejść i popatrzeć - jest to określane jako najbardziej złożone zapytanie SQL, jakie kiedykolwiek napisałeś. Bo wierzcie mi, że to się kompiluje, to działa. A jeśli wycinasz i wklejasz i po prostu próbujesz stworzyć bazę danych, jest to coś do oglądania; jeśli masz narzędzia do oglądania bazy danych, po prostu spróbuj stopić się w ciągu trzech do pięciu minut, aby oddzwonić, co jest jedną linią.
Podsumowując, mając to na uwadze, całe moje doświadczenie w kodowaniu nauczyło mnie, że możesz dawać ludziom broń, a jeśli nie będą ostrożni, strzelą sobie w stopę; sztuką jest pokazanie im, gdzie jest mechanizm bezpieczeństwa. Dzięki odpowiednim narzędziom i oprogramowaniu na wyciągnięcie ręki, po zakończeniu kodowania możesz przejrzeć swój kod, możesz znaleźć problemy poprzez profilowanie kodu, możesz znaleźć skutecznie niezamierzone błędy, które są problemami z wydajnością, i jak powiedziałem wcześniej , dawno temu można to zrobić, patrząc na zielony ekran. Nie możesz już więcej; istnieją setki tysięcy linii kodu, dziesiątki tysięcy aplikacji, w niektórych przypadkach istnieją miliony baz danych, a nawet super ludzie nie mogą już tego robić ręcznie. Potrzebujesz dosłownie odpowiedniego oprogramowania i odpowiednich narzędzi na wyciągnięcie ręki, a zespół potrzebuje tych narzędzi, abyś mógł znaleźć te problemy i rozwiązać je bardzo szybko, zanim dojdziesz do sedna sprawy, podczas gdy Dr. Robin Bloor podkreślił, że rzeczy stają się katastrofalne, a rzeczy wysadzają się w powietrze, lub częściej, po prostu zaczynają cię kosztować dużo dolarów i dużo czasu i wysiłku oraz niszczą morale i inne rzeczy, gdy nie mogą zrozumieć, dlaczego rzeczy biorą długi czas na ucieczkę.
Mając to na uwadze, zamierzam przekazać naszemu gościowi i czekam na wiadomość, jak rozwiązali ten problem. Zwłaszcza demo, które, jak sądzę, miało się wkrótce pojawić. Eric, zemdleję.
Eric Kavanagh: OK, Bert, zabierz to.
Bert Scalzo: Ok dziękuję. Bert Scalzo tutaj z IDERA, jestem menedżerem produktu dla naszych narzędzi baz danych. I zamierzam mówić o debugowaniu. Myślę, że jedną z najważniejszych rzeczy, które Robin powiedział wcześniej - i jest to prawdą, że debugowanie jest uciążliwe i nietrywialne, a kiedy przechodzisz do debugowania bazy danych, jest to rząd wielkości jeszcze bardziej uciążliwy i nietrywialny - tak, że był ważnym cytatem.
DOBRZE. Chciałem zacząć od historii programowania, ponieważ wiele razy widzę ludzi, którzy nie debugują, nie używają debugera, po prostu programują w jakimkolwiek języku, którego używają, i często mówią mi: „Cóż, te debuggery są nowe i nie zaczęliśmy ich jeszcze używać. ”I dlatego pokazuję im ten wykres na osi czasu, coś w rodzaju prehistorii, starości, średniowiecza, to znaczy, gdzie jesteśmy warunki języków programowania. W 1951 roku mieliśmy bardzo stare języki z kodem asemblera oraz Lisp, FACT i COBOL. Następnie wchodzimy do następnej grupy, Pascals i Cs, a następnie do następnej grupy, C ++, i patrzymy, gdzie jest ten znak zapytania - ten znak zapytania jest w przybliżeniu około 1978 do może 1980 roku. Gdzieś w tym przedziale mieliśmy dostępne dla nas debuggery, i tak powiem: „Hej, nie używam debugera, bo to jedna z tych nowych rzeczy”, to musiałeś zacząć programować, wiesz, w latach 50., bo to jedyny sposób, w jaki dostaniesz od tego roszczenia.
Kolejną zabawną rzeczą w tym wykresie jest to, że Dez właśnie skomentował Grace Hopper, tak naprawdę znałem Grace, więc jest to trochę zabawne. A potem jeszcze jedna rzecz, z której się śmiałem, to to, że mówił o teletypach i siedzę tam, mówiąc: „Człowieku, to był największy skok, jaki kiedykolwiek mieliśmy pod względem produktywności, kiedy przechodziliśmy od kart do teletypów, był to największy skok w historii”. , i programowałem już we wszystkich językach, w tym w SNOBOL, o których nikt wcześniej nie słyszał, była to CDC, Control Data Corporation, więc chyba staję się trochę za stary dla tej branży.
Dez Blanchfield: Chciałem powiedzieć, że strasznie nas tam postarzeliście.
Bert Scalzo: Tak, mówię ci, czuję się jak dziadek Simpson. Więc patrzę na debugowanie i są różne sposoby debugowania. Możesz mówić o tym, co wszyscy uważamy za tradycyjne wchodzenie w debugger i przechodzenie przez kod. Ale także ludzie będą instrumentować swój kod; to tam wstawiasz instrukcje do swojego kodu i być może tworzysz plik wyjściowy, plik śledzenia lub coś takiego, więc instrumentujesz swój kod. Policzyłbym to jako debugowanie, jest to trochę trudniejsze, sposób na zrobienie tego, ale to się liczy. Ale mamy też słynne oświadczenie: oglądasz, a ludzie faktycznie umieszczają oświadczenia i faktycznie widziałem narzędzie, w którym - i to narzędzie bazy danych - gdzie, jeśli nie wiesz, jak korzystać z debuggera, naciskasz przycisk, a on się przyklei instrukcje w całym kodzie dla ciebie, a kiedy skończysz, naciskasz inny przycisk i usuwa je. Ponieważ tak wiele osób debuguje.
Powód, dla którego debugujemy, jest dwojaki: po pierwsze musimy znaleźć rzeczy, które powodują, że nasz kod jest nieskuteczny. Innymi słowy, zazwyczaj oznacza to błąd logiczny lub nie spełniliśmy wymagań biznesowych, ale kod jest nieskuteczny; nie robi tego, czego się spodziewaliśmy. Innym razem, gdy idziemy i debugujemy, to pod kątem wydajności i to może być logiczny błąd, ale to, co zrobiłem, to, że zrobiłem właściwą rzecz, po prostu nie wraca wystarczająco szybko. Teraz robię to, ponieważ profilery prawdopodobnie lepiej pasują do tego drugiego scenariusza i zamierzają rozmawiać zarówno o debuggerach, jak i profilerach. Ponadto istnieje koncepcja zdalnego debugowania; jest to ważne, ponieważ wiele razy, jeśli siedzisz na komputerze osobistym i używasz debugera, który trafia do bazy danych, w której kod jest faktycznie wykonywany w bazie danych, faktycznie robisz tak zwane zdalne debugowanie. Możesz nie zdawać sobie z tego sprawy, ale tak się dzieje. A potem bardzo często zdarza się, że te debuggery mają punkty przerwania, punkty obserwacyjne, wkraczają i przechodzą oraz kilka innych wspólnych rzeczy, które za chwilę pokażę na migawce ekranu.
Teraz profilowanie: możesz wykonywać profilowanie na kilka różnych sposobów. Niektórzy powiedzą, że przechwytywanie i odtwarzanie obciążenia odbywa się tam, gdzie przechwytuje wszystko, co liczy się jako profilowanie. Moje doświadczenie było bardziej lepsze, jeśli wykonałem próbkowanie. Nie ma powodu, aby łapać każdą pojedynczą instrukcję, ponieważ niektóre instrukcje mogą po prostu działać tak szybko, że nie obchodzi cię to, co naprawdę próbujesz zobaczyć, to są te, które pojawiają się w kółko, ponieważ działają zbyt długo . Tak więc czasami profilowanie może oznaczać próbkowanie, a nie uruchamianie całości. I zazwyczaj otrzymasz jakiś wynik, którego możesz użyć, teraz, który może być wizualny w środowisku programistycznym IDE, gdzie może dać ci histogram wydajności różnych linii kodu, ale może również nadal ponieważ tworzy plik śledzenia.
Profile pojawiły się po raz pierwszy w 1979 roku. Te też istnieją już od dawna. Idealne do znajdowania zużycia zasobów lub problemów z wydajnością, innymi słowy, że wydajność. Ogólnie rzecz biorąc, jest on odrębny i odmienny od debuggera, chociaż pracowałem z debuggerami, które robią oba jednocześnie. I chociaż uważam, że profilery są bardziej interesujące z tych dwóch narzędzi, jeśli uważam, że za mało ludzi debuguje, to zdecydowanie za mało ludzi profiluje, ponieważ wydaje się, że jeden na dziesięciu debugerów będzie się profilował. A szkoda, bo profilowanie może naprawdę zrobić ogromną różnicę. Otóż języki baz danych, o których mówiliśmy wcześniej, mają SQL - i w pewnym sensie zmusiliśmy okrągły kołek do kwadratowej dziury i zmusiliśmy go, aby stał się językiem programowania - i Oracle.To jest PL / SQL - to jest język proceduralny SQL - i SQL Server, jego Transact-SQL, SQL-99, SQL / PSM - dla, jak sądzę, jego modułu przechowywanego w procedurze. Postgres nadaje mu inną nazwę, DB2 jeszcze inną nazwę, Informix, ale chodzi o to, że wszyscy wymusili konstrukcje typu 3GL; innymi słowy, pętle FOR, deklaracje zmiennych i wszystkie inne elementy obce SQL są teraz częścią SQL w tych językach. Tak więc musisz mieć możliwość debugowania PL / SQL lub Transact-SQL, podobnie jak program Visual Basic.
Teraz, obiekty bazy danych, jest to ważne, ponieważ ludzie powiedzą: „Cóż, co muszę debugować w bazie danych?”. Odpowiedź brzmi: cóż, cokolwiek możesz zapisać w bazie danych jako kod - jeśli robię T- SQL lub PL / SQL - i Im przechowują obiekty w bazie danych, prawdopodobnie jest to procedura składowana lub funkcja składowana. Ale są też wyzwalacze: wyzwalacz jest czymś w rodzaju procedury składowanej, ale uruchamia się przy jakimś zdarzeniu. Teraz niektóre osoby w swoich wyzwalaczach wstawią jeden wiersz kodu i wywołają procedurę przechowywaną, aby zachować cały przechowywany kod i procedury, ale jest to ta sama koncepcja: to wciąż wyzwalacz może być tym, co inicjuje całość. A potem jako Oracle mają coś, co nazywa się pakietem, co jest jakby biblioteką, jeśli wolisz. Umieszczasz 50 lub 100 procedur przechowywanych w jednej grupie, zwanej pakietem, więc jest to coś w rodzaju biblioteki. Oto debugger po staremu; w rzeczywistości jest to narzędzie, które faktycznie wklei wszystkie te instrukcje debugowania w kodzie. Tak więc, wszędzie tam, gdzie widzisz blok debugowania, nie usuwaj, uruchamianie i śledzenie automatycznego debuggera, wszystkie one utknęły w jakimś narzędziu. A poza tym wiersze, które stanowią mniejszość kodu, no cóż, to nie jest ręczna metoda debugowania.
Powodem, dla którego to poruszam, jest to, że jeśli próbujesz to zrobić ręcznie, w rzeczywistości będziesz pisać więcej kodu do debugowania, aby wstawić wszystkie te instrukcje niż z kodem. Chociaż może to działać i jest lepsze niż nic, jest to bardzo trudny sposób na debugowanie, zwłaszcza, że jeśli zajmie to 10 godzin, aby uruchomić tę rzecz, a gdzie ma problem, jest na trzeciej linii? Gdybym robił interaktywną sesję debugowania, wiedziałbym na linii trzeciej - pięć minut - hej, tu jest problem, mogę wyjść. Ale z tym musiałem poczekać, aż się uruchomi, aż do zakończenia, a potem zajrzałem do pliku śledzenia, który prawdopodobnie zawiera wszystkie te instrukcje, i próbowałem znaleźć igłę w stogu siana. Znowu jest to lepsze niż nic, ale nie byłby to najlepszy sposób pracy. Tak właśnie wyglądałby ten plik, który pochodzi z poprzedniego slajdu; innymi słowy, uruchomiłem program, a on właśnie dostał kilka instrukcji w tym pliku śledzenia i mogę, ale nie muszę, przesączyć przez to i znaleźć to, co muszę znaleźć. Więc znowu, nie jestem pewien, czy właśnie tak chciałbyś pracować.
Teraz interaktywne debugery - a jeśli używałeś czegoś takiego jak Visual Studio do pisania programów lub Eclipse, miałeś debugery i korzystałeś z nich w innych językach - po prostu nie pomyślałem, aby użyć ich tutaj z bazą danych. Istnieją narzędzia, takie jak nasz DB Artisan i nasz Rapid SQL, tutaj jest Rapid SQL, które mają debugger, a po lewej stronie widać procedurę składowaną o nazwie „sprawdź duplikaty”. Zasadniczo, po prostu pójdę i zobaczę, czy mam wiele wierszy w tabeli o tym samym tytule filmowym. Baza danych dotyczy filmów. I widać po prawej stronie, w górnej trzeciej, mam kod źródłowy w środku, mam tak zwane moje zmienne zegarka i tace stosu wywołań, a następnie na dole mam jakieś dane wyjściowe. Ważne jest to, że jeśli spojrzysz na tę pierwszą czerwoną strzałkę, jeśli najecham myszką na zmienną, faktycznie zobaczę, jaka wartość jest w tej chwili w danej chwili, gdy przechodzę przez kod. I to jest naprawdę przydatne, a następnie mogę krok po kroku przejść przez kod, nie muszę mówić o wykonaniu, mógłbym powiedzieć krok po kroku, pozwól mi spojrzeć, co się stało, krok po kroku, pozwól mi zobaczyć, co się stało, i Robię to w bazie danych. I mimo że siedzę na Rapid SQL na moim komputerze, a moja baza danych jest w chmurze, nadal mogę zdalnie debugować i widzieć go i kontrolować z tego miejsca, a także debugować tak, jak w innym języku.
Teraz następna strzałka tam - możesz zobaczyć małą strzałkę skierowaną w prawo, w stronę wyjścia DBMS, czyli tam, gdzie obecnie znajduje się mój kursor - innymi słowy, zrobiłem krok i właśnie tam jestem w tej chwili. Więc jeśli powiem: „Zrób krok ponownie”, przejdę do następnej linii. Teraz tuż poniżej zobaczysz czerwoną kropkę. Cóż, to jest punkt przerwania, który mówi: „Hej, nie chcę przekraczać tych linii”. Jeśli chcę po prostu przeskoczyć wszystko i dojść do miejsca, w którym czerwona kropka, mogę nacisnąć przycisk uruchamiania, a to z tego miejsca biegnie do końca lub do punktu przerwania, jeśli są ustawione jakieś punkty przerwania, a następnie zatrzyma się i pozwoli mi powtórzyć krok. A powodem tego jest to, że wszystko jest ważne i potężne, ponieważ kiedy robię to wszystko, co dzieje się na środku, a nawet na dole - ale co najważniejsze w środku - zmieni się i widzę wartości z moich zmiennych, mogę widzę mój ślad stosu wywołań, wiesz, więc wszystkie te informacje są tam wyświetlane, gdy przechodzę przez kod, więc właściwie widzę, czuję i rozumiem, co się dzieje i jak kod działa w czasie wykonywania . I zazwyczaj mogę znaleźć problem, jeśli taki istnieje, lub jeśli jestem wystarczająco dobry, aby go złapać.
OK, teraz zamierzam porozmawiać o profilerze, aw tym przypadku jest to profiler, który widzę przez debugger. Pamiętasz, jak mówiłem, że czasami są oddzielni, a czasem mogą być razem? W tym przypadku, i znowu, Im w Rapid SQL, i widzę margines, po lewej stronie, obok numerów linii. I to znaczy tyle, ile sekund zajęło wykonanie każdej linii kodu, i widzę to wyraźnie, cały mój czas spędzam w tej jednej pętli FOR, w której wybieram wszystko z tabeli. I tak, obserwujący wydarzenia wewnątrz pętli FOR to prawdopodobnie coś, na co muszę spojrzeć, a jeśli uda mi się to poprawić, przyniesie to dywidendy. Nie zamierzam uzyskać żadnych ulepszeń, pracując na liniach, które mają 0,90 lub 0,86; nie spędza się tam dużo czasu. Teraz, w tym przypadku, i znowu, Im w Rapid SQL, widzisz, jak mogę profilować zmieszane z moim debugowaniem. Teraz fajne jest to, że Rapid SQL pozwala ci to zrobić w drugą stronę. Rapid SQL pozwala powiedzieć: „Wiesz co? Nie chcę być w debugerze, po prostu chcę to uruchomić, a następnie chcę spojrzeć na graficznie lub wizualnie ten sam rodzaj informacji. ”
I widać, że nie jestem już w debuggerze i uruchamia on program, a po zakończeniu wykonywania daje mi wykresy, aby powiedzieć mi rzeczy, dzięki czemu mogę zobaczyć, że mam jedną instrukcję, która wygląda, jakby zajmowała większość ciasta wykres i jeśli patrzę, widzę na tej siatce w kierunku dołu, wiersz 23, znowu tam jest pętla FOR: zajmuje najwięcej czasu, w rzeczywistości ciemnoczerwony żuje cały wykres kołowy. To kolejny sposób na profilowanie. W naszym narzędziu nazywamy tego „Code Analyst”. Ale to w zasadzie tylko profiler oddzielony od debuggera. Niektórzy ludzie lubią to robić w pierwszy sposób, inni lubią to w drugi sposób.
Dlaczego debugujemy i profilujemy? Nie dlatego, że chcemy napisać najlepszy kod na świecie i uzyskać podwyżkę - to może być nasz powód, ale to nie jest tak naprawdę powód, dla którego to robisz - obiecałeś firmie, że zrobisz coś poprawnie, że Twój program będzie skuteczny. Do tego będzie używany debugger. Ponadto biznesowi użytkownicy końcowi; nie są zbyt cierpliwi: chcą wyników nawet przed naciśnięciem klawisza. Mieliśmy czytać w ich myślach i robić wszystko natychmiast. Innymi słowy, musi być wydajny. I do tego właśnie użylibyśmy profilera. Teraz, bez tych narzędzi, naprawdę wierzę, że jesteś tym facetem w garniturze z łukiem i strzałą, strzelasz do celu i masz zasłonięte oczy. Ponieważ jak dowiesz się, jak program działa, patrząc tylko na kod statyczny i jak dowiedzieć się, w którym wierszu tak naprawdę spędziłby najwięcej czasu, ponownie, patrząc tylko na kod statyczny? Przegląd kodu może, ale nie musi, ujawnić niektóre z tych rzeczy, ale nie ma gwarancji, że przegląd kodu znajdzie je wszystkie. Za pomocą debugera i profilera powinieneś być w stanie znaleźć wszystkie te błędy.
OK, zamierzam zrobić tutaj naprawdę szybkie demo. Nie mam zamiaru pchać produktu, chcę tylko pokazać, jak wygląda debugger, ponieważ wiele razy ludzie mówią: „Nigdy wcześniej nie widziałem żadnego z nich”. I wygląda to ładnie na zrzutach ekranowych, ale co wygląda jak kiedy jest w ruchu? Tak więc tutaj na moim ekranie korzystam z produktu DB Artisan; mamy tam również debugger. DB Artisan jest przeznaczony bardziej dla DBA, Rapid SQL jest bardziej dla programistów, ale widziałem programistów, którzy używają DB Artisan, i widziałem DBA, którzy używają Rapid. Więc nie daj się złapać na produkcie. I tutaj mam wybór zrobienia debugowania, ale zanim uruchomię debugowanie, wyodrębnię ten kod, abyś mógł zobaczyć, jak wygląda kod, zanim zacznę go uruchamiać. Oto dokładnie ten sam kod, który znajdował się w migawce ekranu, oto moje sprawdzenie duplikatów. Chcę to debugować, więc naciskam debugowanie. A teraz zajmuje to chwilę i mówisz: „Cóż, dlaczego zajmuje to chwilę?”. Pamiętasz zdalne debugowanie: debugowanie odbywa się na moim serwerze bazy danych, a nie na komputerze. Musiał więc przejść i stworzyć tam sesję, stworzyć zdalne debugowanie, podłączyć moją sesję do tej zdalnej sesji debugowania i skonfigurować kanał komunikacyjny.
A więc, oto moja strzałka, jest tam na górze, w pierwszej linii, tam jestem w kodzie. A jeśli nacisnę tam trzecią ikonę, która jest krokiem do przodu, zobaczysz, że ta strzała właśnie się poruszyła, a jeśli będę ją naciskał, zobaczysz, że się porusza. Teraz, gdybym chciał przejść do tej pętli FOR, ponieważ wiem, na czym polega problem, mogę ustawić punkt przerwania. Myślałem, że to ustawiłem. Och, strzel, miałem jeden z moich klawiszy przechwytywania ekranu przypisany do tego samego klucza co debugger, co powoduje zamieszanie. OK, więc po prostu ręcznie ustawiłem tam punkt przerwania, więc teraz zamiast robić krok, krok, krok, krok, aż do niego dojdę, właściwie mogę po prostu powiedzieć: „Idź naprzód i uruchom tę rzecz”, a ona się zatrzyma. Zauważ, że przesunęło mnie to do miejsca, w którym znajduje się punkt przerwania, więc jestem teraz w trakcie uruchamiania tej pętli, widzę, na co ustawione są wszystkie moje zmienne, co nie jest zaskoczeniem, ponieważ zainicjowałem je wszystkie zero. A teraz mogę wejść w tę pętlę i zacząć patrzeć na to, co dzieje się w tej pętli.
Więc teraz zrobię wybrane obliczenie z moich wypożyczalni i mogę najechać myszką na tego faceta i spojrzeć, on ma dwa, dwa są większe niż jeden, więc prawdopodobnie zrobi następny fragment tego kodu. Innymi słowy, znalazł coś. Po prostu zamierzam iść naprzód i pozwolić temu biegać. Nie chcę tutaj wszystkiego przechodzić; to, co chcę ci pokazać, to kiedy debugger jest gotowy, kończy się tak jak normalny program. Mam ustawiony punkt przerwania, więc kiedy powiedziałem „biegnij”, po prostu wróciłem do następnego punktu przerwania. Pozwolę mu działać do końca, bo chcę, abyś zobaczył, że debugger nie zmienia zachowania programu: po zakończeniu pracy powinienem uzyskać dokładnie takie same wyniki, jeśli nie uruchomiłem go w debuggerze.
I po tym, zamierzam zawiesić wersję demo i wrócić, bo chcemy mieć czas na pytania i odpowiedzi. I tak otworzę go na pytania i odpowiedzi.
Eric Kavanagh: W porządku, Robin, może pytanie od ciebie, a potem kilka od Deza?
Robin Bloor: Tak, oczywiście, uważam to za fascynujące. Pracowałem z takimi rzeczami, ale nigdy nie pracowałem z czymś takim w bazie danych. Czy możesz mi powiedzieć, do czego ludzie używają profilera? Ponieważ to tak, czy patrzą - bo zakładam, że tak - patrzą na problemy z wydajnością, czy pomoże ci to odróżnić, kiedy baza danych wymaga czasu, a kiedy kod zajmuje czas?
Bert Scalzo: Wiesz, to fantastyczne pytanie. Powiedzmy, że pracuję w języku Visual Basic, a ja w swoim Visual Basic Im zadzwonię do Transact-SQL lub PL / SQL. Pozwól mi zrobić PL / SQL, ponieważ Oracle nie zawsze dobrze gra z narzędziami Microsoft. Być może profiluję swój kod Visual Basic, a profil może powiedzieć: „Hej, wywołałem tę procedurę przechowywaną i zajęło to zbyt długo”. Ale potem mogę przejść do procedury przechowywanej i mogę wykonać profil bazy danych na przechowywanym i powiedz: „OK, na 100 stwierdzeń, które są tutaj, oto pięć, które były przyczyną problemu”. Może być więc konieczne utworzenie zespołu tagów, w którym trzeba użyć wielu profilerów.
Chodzi o to, że jeśli kiedykolwiek dowiesz się, że problem z wydajnością znajduje się w bazie danych, profil bazy danych może pomóc Ci znaleźć igłę w stogu siana, na której stwierdzeniach faktycznie występują te, w których masz problem. Mówię wam o innej rzeczy, która pojawiła się w przypadku profilowania: jeśli masz kawałek kodu, który jest wywoływany milion razy, ale zajmuje to tylko mikrosekundę każdego miliona razy, ale jest wywoływany milion razy, co pokaże profiler , to działało przez tak wiele jednostek czasu. I chociaż kod może być bardzo wydajny, możesz spojrzeć i powiedzieć: „Och, zbyt często dzwoniłem do tego fragmentu kodu. Może powinniśmy to nazywać tak często, a nie za każdym razem, gdy przetwarzamy nagranie ”czy coś takiego. Dzięki temu możesz naprawdę znaleźć, gdzie jest skuteczny kod, który jest zbyt często wywoływany, a to w rzeczywistości problem z wydajnością.
Robin Bloor: Tak, to wspaniale. Nigdy tego nie robiłem. Widzisz, oczywiście, kiedy miałem problemy z bazą danych, to tak, jakbym w ten czy inny sposób zajmował się bazą danych lub kodem; Nigdy nie mogłem poradzić sobie z oboma jednocześnie. Ale znowu nie zrobiłem - nigdy nie brałem udziału w tworzeniu aplikacji, w których mieliśmy procedury składowane, więc chyba nigdy nie napotkałem problemów, które doprowadzały mnie do szaleństwa - pomysł, że podzielisz kod na baza danych i program. Ale tak, zrób wszystko… Zakładam, że odpowiedzi będą twierdzące, ale jest to część działalności zespołu programistów, gdy w ten czy inny sposób próbujesz naprawić coś, co jest zepsute, lub może próbujesz połączyć nową aplikację. Ale czy to wszystko pasuje do wszystkich innych elementów, których oczekiwałbym w środowisku? Czy mogę się spodziewać, że mógłbym to zrobić razem ze wszystkimi moimi pakietami testowymi i wszystkimi innymi rzeczami, które bym robił oraz z rzeczami związanymi z zarządzaniem projektami, czy tak to wszystko razem łączy?
Bert Scalzo: Tak, może stać się częścią każdego ustrukturyzowanego procesu programowania lub rozwoju. I to zabawne, w zeszłym tygodniu miałem klienta, który budował aplikację internetową, a ich baza danych była historycznie niewielka, więc fakt, że nie byli bardzo dobrymi programistami, nigdy ich nie skrzywdził. Cóż, ich baza danych rozrosła się przez lata, a teraz zajmuje 20 sekund na stronie internetowej, od kiedy powiesz „Zaloguj mnie i daj mi trochę danych do zobaczenia”, a kiedy ekran faktycznie się pojawi, a więc teraz jest problem z wydajnością. I wiedzieli, że problem nie występuje w żadnym języku Java ani w żadnym innym miejscu. Ale mieli tysiące procedur przechowywanych i dlatego musieli rozpocząć profilowanie procedur przechowywanych, aby dowiedzieć się, dlaczego ta strona internetowa zajmuje 20 sekund? I faktycznie odkryliśmy, że mieli kartezjańskie przyłączenie w jednym ze swoich wybranych oświadczeń i nie wiedzieli o tym.
Robin Bloor: Łał.
Bert Scalzo: Ale ktoś powiedział mi kiedyś: „Jak mogliby dołączyć do kartezjańskiego króla i nie wiedzieć o tym?” I to brzmi naprawdę okropnie; czasami programista, który nie jest zbyt dobrze zaznajomiony z SQL, zrobi coś takiego, jak dać mi kartezjańskie połączenie, ale potem zwróci mi tylko pierwszy rekord, więc wiem, że coś mam i potrzebuję tylko pierwszego. I tak, nie zdają sobie sprawy, że właśnie przywrócili miliard płyt lub przeglądają miliard płyt, bo dostali tę, którą byli zainteresowani.
Robin Bloor: Wow, wiem, tak to się nazywa - no cóż, o to właśnie chodziło Dez, jeśli chodzi o ludzi, którzy nie są tak wykwalifikowani, jak być może powinni. Jeśli jesteś programistą, powinieneś wiedzieć, jakie są implikacje wydania dowolnego polecenia. Chodzi mi o to, że nie ma usprawiedliwienia dla tego poziomu głupoty. Zakładam również, że jesteś w ten czy inny sposób obojętny wobec języka, ponieważ wszystko koncentruje się na stronie bazy danych. Czy mam rację? Czy to tak samo, niezależnie od tego, czego używasz po stronie kodującej?
Bert Scalzo: Oczywiście możesz to zrobić w Fortran, C lub C ++. W rzeczywistości, w niektórych Uniksach możesz to zrobić nawet dla ich języków skryptowych; faktycznie zapewniają te same narzędzia. A potem chcę cofnąć się o sekundę po to, co powiedziałeś bez żadnej wymówki. Dam programistom jedną przerwę, bo nie lubię rzucać programistów pod autobus. Ale problemem jest tak naprawdę środowisko akademickie, ponieważ kiedy idziesz uczyć się, jak być programistą, uczysz się rekordowego myślenia. Nie uczy się myślenia o ustawieniach, i to właśnie język zapytań strukturalnych lub SQL działa z zestawami; dlatego mamy operator unii, przecięcia i operatora minus. A czasem bardzo trudno jest osobie, która nigdy nie myślała w kategoriach zestawów, rzucić palenie, puścić przetwarzanie nagrań na raz i pracować z zestawami.
Robin Bloor: Tak, jestem z tobą w tej sprawie. Rozumiem, że to kwestia edukacji; Myślę, że jest to całkowicie kwestia edukacji, myślę, że to naturalne, że programiści myślą proceduralnie. A SQL nie jest proceduralny, jest deklaratywny. Mówisz po prostu: „Tego właśnie chcę i nie obchodzi mnie, jak to robisz”, wiesz? Podczas gdy w językach programowania często masz rękawy podwijane i przechodzisz do drobiazgów nawet zarządzania liczeniem podczas wykonywania pętli. Zła ręka do…
Bert Scalzo: Nie. OK, kontynuuj.
Tak, chciałem powiedzieć, że przywołałeś jeszcze jeden przykład, że profiler byłby dobry w łapaniu tego, co dzieje się z tym przetwarzaniem nagrań na raz. Czasami programista, który jest dobry w logice zapisywania na raz, nie może zrozumieć, jak wykonać program SQL. Powiedzmy, że tworzy dwie pętle FOR i wykonuje sprzężenie, ale robi to po stronie klienta. Tak więc robi ten sam efekt co złączenie, ale robi to sam, a profil by to złapał, ponieważ prawdopodobnie skończyłbyś spędzać więcej czasu na ręcznym łączeniu, niż pozwalając, aby serwer bazy danych zrobił to za ciebie.
Robin Bloor: Tak, to byłaby katastrofa. Chodzi mi o to, że rzucasz się w kółko. Thrashings zawsze złe.
W każdym razie źle przekażę Dezowi; Jestem pewien, że ma kilka interesujących pytań.
Dez Blanchfield: Dziękuję tak. Dołączę do was w nie rzucających programistów pod autobus. Mam na myśli, że spędziłem zbyt wiele lat w życiu jako programista, na każdym poziomie, wiesz, czy to tak, jak powiedziałeś, siedząc na linii poleceń maszyny uniksowej, aw niektórych przypadkach byłem nawet zaangażowany w kilka różnych portów Uniksa z jednej platformy sprzętowej na drugą. I możesz sobie wyobrazić wyzwania, które tam mieliśmy. Ale rzeczywistość jest taka, że karta wyjścia z więzienia dla każdego kodera i skryptera na świecie. Jest to nauka o rakietach, dosłownie, pisanie naprawdę ciasno za każdym razem, przez cały czas, jest nauką o rakietach. I słynne historie ludzi takich jak Dennis Ritchie i Brian Kernahan, którzy pracują nad jakimś fragmentem kodu niezależnie, a następnie przychodzą na przegląd kodu, rozmawiają przy kawie i dowiadują się, że napisali dokładnie ten sam fragment kodu, dokładnie w tym samym programie, dokładnie w ten sam sposób. I zrobili to w C. Ale ten purystyczny poziom programowania istnieje bardzo rzadko.
Faktem jest, że codziennie jest tylko 24 godziny na dobę, siedem dni w tygodniu, a my po prostu musimy załatwić sprawę. I tak, jeśli chodzi o nie tylko tradycyjnych programistów, DBA i kodery, i skrypty, sysadmin, administratorzy sieci, pracownicy ochrony i wszystko, aż do dzisiejszych czasów - po stronie danych obywateli; słyszymy, że wszyscy po prostu próbują wykonać swoją pracę. I dlatego uważam, że najlepsze na wynos z tego wszystkiego jest to, że uwielbiam twoje demo i uwielbiam to, co zostawiłeś nam przed chwilą, rozmawiając z Robin o tym, że ma to coś szczególnego - może nie tyle nisza - ale szeroka przestrzeń, której dotyczy, w zakresie poprawiania kodu oraz SQL i baz danych. Ale byłem bardzo podekscytowany słysząc, jak mówisz, że możesz wbić go w skrypt powłoki i znaleźć pewne problemy, ponieważ wiesz, że w dzisiejszych czasach zawsze pracowali na najniższy koszt.
Powodem, dla którego możesz gdzieś kupić koszulę za 6 USD, jest to, że ktoś zbudował system na tyle tanio, aby faktycznie produkować i wysyłać oraz logistycznie dostarczać, sprzedawać i sprzedawać detalicznie oraz przyjmować płatności online, aby otrzymać tę koszulę za 6 USD. I tak się nie stanie, jeśli ludzie będą zarabiać 400 000 USD rocznie za perfekcyjne pisanie kodu; to tylko cały rozwój. Myślę więc, że jednym z pytań, które naprawdę cię kocham, by dać nam więcej informacji, jest zasięg i zasięg ludzi, których obecnie widzisz, którzy wdrażają tego rodzaju narzędzia do profilowania kodu i wyglądu w przypadku problemów z wydajnością? Początkowo, skąd pochodzą? Czy były to duże domy inżynieryjne? I dalej, czy tak jest w istocie, czy mam rację, myśląc, że coraz więcej firm wdraża to narzędzie lub te narzędzia, aby spróbować pomóc programistom, którzy wiedzą, którzy właśnie wykonują zadania, aby ukończyć pracę i wydostać się przez drzwi? A czasem potrzebujemy karty wychodzenia z więzienia? Czy mam rację, myśląc, że historycznie skupiliśmy się na inżynierii i rozwoju? Że teraz mniej, jak powiedział Robin, było podejście akademickie, a teraz jego samouk, kod do wycinania i wklejania, czy po prostu tworzenie rzeczy? Czy to pasuje do ludzi, którzy biorą teraz ten produkt?
Bert Scalzo: Tak, dokładnie. I dam ci bardzo konkretny przykład, chcemy po prostu wykonać pracę, ponieważ ludzie biznesu nie chcą perfekcji. To trochę jak komputerowa gra w szachy: gra w szachy nie szuka idealnej odpowiedzi; szuka odpowiedzi, która jest wystarczająco dobra w rozsądnym czasie, więc tak programujemy. Ale to, co teraz znajduję, większość ludzi zamiast mówić, że chce profilera w ramach ich testów jednostkowych - tak właśnie bym to zrobił, ponieważ nie uważam tego za stratę czasu - to, co się dzieje, teraz później, czasem, podczas testów integracyjnych lub testów warunków skrajnych, jeśli mieli szczęście. Ale przez większość czasu jest to część eskalacji, w której coś poszło do produkcji, działało przez jakiś czas, może nawet działało przez lata, a teraz nie działa dobrze, a teraz dobrze je profiluje. I wydaje się, że jest to teraz bardziej powszechny scenariusz.
Dez Blanchfield: Tak, i myślę, że termin „dług techniczny” jest prawdopodobnie tym, który jest ci bardziej niż zaznajomiony; Wiem, że Robin i ja na pewno jesteśmy. Myślę, że w dzisiejszych czasach, szczególnie w zwinnym podejściu do programowania i budowania systemu, koncepcja długu technicznego jest teraz bardzo realna i faktycznie uwzględniamy to w projektach. Wiem, że mamy własne projekty, takie jak Media Lens i inne, w których kodowanie odbywa się codziennie i różne rzeczy w całej Bloor Group. I za każdym razem, gdy coś budujemy, patrzymy na to, patrzę na to i zawsze patrzę z punktu widzenia tego, co będzie mnie kosztować, aby naprawić to teraz, w porównaniu do tego, czy mogę to po prostu umieścić w puszce i weź to tam, a następnie obserwuj i zobacz, czy to się zepsuje. I odziedziczę ten dług techniczny, o którym wiem, że muszę go później naprawić i naprawić.
Mam na myśli, że zrobiłem to w ciągu ostatnich siedmiu dni: napisałem kilka narzędzi i skryptów, napisałem kilka elementów języka Python i wdrożyłem go na zapleczu Mongo, upewniając się, że jest ładny, czysty i bezpieczny, ale po prostu dostaje zapytanie, którego potrzebuję, wiedząc, że potrzebuję tej funkcji do działania, aby dostać się do większej układanki; tam jest mój prawdziwy ból. Więc zaciągasz ten dług techniczny i myślę, że teraz nie jest to tylko okazjonalna sprawa, myślę, że jest to część DNA rozwoju. Ludzie po prostu - nie nieuczciwie - po prostu akceptują dług techniczny, który jest normalnym rodzajem problemu i muszą go ponieść. To tam zaciągasz dług techniczny. I myślę, że największą zaletą tego, co pokazałeś nam w wersji demo, było to, że możesz dosłownie profilować i obserwować, jak długo trwa uruchomienie. I to prawdopodobnie jedna z moich ulubionych rzeczy. Mam na myśli, że faktycznie zbudowałem narzędzia do profilowania - budowaliśmy narzędzia w Sed, Lex i Orc do uruchamiania naszego kodu i sprawdzania, gdzie są pętle, zanim takie narzędzia były dostępne - i kiedy budowałeś kod, aby przejść i przejrzeć własny kod , bardzo dobrze radzisz sobie z nie przeglądaniem własnego kodu. Ale teraz tak nie jest. Mając to na uwadze, czy istnieje jakiś segment rynku, który zajmuje się tym bardziej niż jakikolwiek inny? Widzieć jak masę—
Bert Scalzo: O tak, mam ... Mam zamiar narysować dla ciebie analogię i pokazać, że nie-programiści robią to cały czas. Bo jeśli kiedykolwiek prowadzę zajęcia z debugowania i profilowania lub sesji, źle zapytam ludzi: „OK, ile osób tutaj wchodzi do Microsoft Word i celowo nigdy nie używa sprawdzania pisowni?” I nikt nie podnosi ręki, ponieważ do pisania dokumentów, wszyscy wiemy, że możemy popełniać błędy w języku angielskim, dlatego wszyscy używają sprawdzania pisowni. I powiedziałem: „No cóż, dlaczego pisząc w swoim IDE jak Visual Basic, nie używasz debugera? To to samo, przypomina sprawdzanie pisowni.
Dez Blanchfield: Tak, to świetna analogia. Naprawdę o tym nie myślałem, muszę przyznać, że robię coś podobnego za pomocą kilku narzędzi, których używam. W rzeczywistości, jeden z ODF, mój ulubiony z Eclipse, to po prostu wytnij i wklej tam kod i idź szukać rzeczy, które po prostu wyróżniają się od razu i zdając sobie sprawę, że popełniłem literówkę podczas jakiegoś wywołania klasy. I, ale jest teraz interesujące dzięki takiemu narzędziu, możesz to zrobić w czasie rzeczywistym, zamiast wracać i patrzeć na to później, co jest miłe, aby złapać go z góry. Ale tak, to świetna analogia po prostu włożenia do edytora tekstu, ponieważ jest to interesujące budzenie, po prostu uświadom sobie, że popełniłeś literówki, a nawet błąd gramatyczny, prawda?
Bert Scalzo: Dokładnie.
Dez Blanchfield: Więc, czy widzisz teraz większą poprawę od, jak sądzę, ostatniego pytania ode mnie, zanim rzucę nasze pytania i pytania, być może, dla naszych uczestników. Jeśli zamierzasz dać jakieś zalecenie dotyczące podejścia do tego - zakładam, że jest to retoryczne - czy to jest tak, że przychodzisz wcześnie i wdrażasz to w trakcie rozwoju, zanim się rozwijasz? A może przeważnie budujesz, ruszasz się, budujesz coś, a potem wchodzisz i profilujesz to później? Podejrzewam, że tak jest w przypadku wczesnego wejścia i upewnij się, że twoje kody są czyste z góry. Czy jest to przypadek, że powinni rozważyć tę część swojego wdrożenia?
Bert Scalzo: Najlepiej zrobiliby to z góry, ale ponieważ wszyscy znajdują się w zgiełku, w którym po prostu muszą załatwić sprawę, zwykle nie robią tego, dopóki nie napotkają problemu z wydajnością, którego nie mogą rozwiązać, dodając więcej procesorów i pamięci na maszynę wirtualną.
Dez Blanchfield: Tak. Więc właściwie wspomniałeś coś interesującego, jeśli mogę szybko? Wspomniałeś wcześniej, że można to uruchomić z dowolnego miejsca i można rozmawiać z bazą danych na zapleczu. Jest to więc wygodne z rodzajem bimodalnej koncepcji, o której teraz mówimy, z chmurą lokalną / pozamiejscową, również z wyglądu, pod koniec dnia, jeśli może porozmawiać z zapleczem i zobaczyć kod, to naprawdę nie obchodzi, prawda?
Bert Scalzo: Dokładnie tak, możesz uruchomić to w chmurze.
Dez Blanchfield: Doskonale, bo myślę, że w tym kierunku zmierza nasz nowy odważny świat. Więc, Eric. Mam zamiar odpowiedzieć ci teraz i przekonać się, że mamy tutaj kilka pytań i chcę, aby nasi uczestnicy pozostali z nami, nawet jeśli minęła już godzina.
Eric Kavanagh: Tak, jest tam kilku ludzi, po prostu zrobię szybki komentarz: Bert, myślę, że ta metafora, analogia, którą podajesz przy użyciu sprawdzania pisowni, jest szczerze mówiąc genialna. To jest warte bloga lub dwóch, szczerze mówiąc, ponieważ jest to dobry sposób na określenie wady tego, co robisz, i jak to jest cenne oraz jak naprawdę powinna być najlepszą praktyką, aby używać debuggera na regularnie, prawda? Założę się, że kilka głów przytakuje, kiedy wyrzucasz tę, prawda?
Bert Scalzo: Oczywiście, ponieważ mówię im: „Dlaczego sprawdzam pisownię w moich dokumentach? Nie chcę się wstydzić głupimi błędami w pisowni. ”No cóż, nie chcą się wstydzić głupimi błędami w kodzie!
Eric Kavanagh: Dobrze. W rzeczy samej. Ludzie, spaliliśmy się tutaj przez godzinę i pięć minut, tak wielkie dzięki wam wszystkim za poświęcony czas i uwagę. Archiwizujemy wszystkie te czaty internetowe, w każdej chwili możesz wrócić i je sprawdzić. Najlepszym miejscem do znalezienia tych linków jest prawdopodobnie techopedia.com, więc dodaj to tutaj do tej listy.
I z tym zamierzali was pożegnać, ludzie. Jeszcze raz świetna robota, Bert, dzięki naszym przyjaciołom z IDERA. Cóż, rozmawiamy z tobą następnym razem, tak naprawdę rozmawiamy z tobą w przyszłym tygodniu. Dbać! PA pa.