От персонала на Техопедия, 15 март 2017 г.
Отнемане: Домакинът Ерик Кавана обсъди отстраняване на грешки и профилиране на базата данни с д-р Робин Блур, Дез Бланчфийлд и Берт Скалцо на IDERA.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Добре, госпожи и господа, в сряда е 4:00 източно време и разбира се това означава.
Робин Блур: Не те чувам, Ерик.
Ерик Кавана: Бях там преди дни, така че не сте сами. Но затова темата днес е наистина интересни неща. Това е нещото, което искате да сте сигурни, че се случва на заден план във вашата компания, освен ако не сте човекът, който прави това, и в този случай искате да сте сигурни, че го правите правилно. Защото говорим за отстраняване на грешки. Никой не обича бъгове, никой не харесва, когато софтуерът престане да работи - хората се разстройват, потребителите стават неприветливи. Това не е добре. Така че, ние ще говорим за "Бързо реагиране: Отстраняване на грешки в базата данни и профилиране до спасяването."
Има място за вашето наистина, ударете ме в Twitter, @eric_kavanagh, разбира се.
Тази година е гореща. И отстраняването на грешки ще бъде горещо, независимо какво. Това наистина ще бъде един от тези проблеми, който никога няма да отмине, без значение колко добри сме в тези неща, винаги ще има проблеми, така че ключът е как да стигнете до мястото, където можете бързо да разрешите тези проблеми? В идеалния случай имате страхотни програмисти, страхотна среда, където не много се обърква, но както се казва в старата поговорка: „Авариите се случват в най-добрите семейства.“ И същото важи за организациите. Така че, тези неща се случват, това ще се случи, въпросът е какво ще бъде вашето решение за справяне с него и решаване на тези проблеми?
Ще чуем от д-р Робин Блур, след това от собствения ни Дез Бланчфийлд отдолу и, разбира се, от нашия добър приятел, Берт Скалцо, от IDERA. И всъщност аз ще връча ключовете на Робин Блур, отнеси го. Подът е ваш.
Robin Bloor: ОК. Това е интересна тема. Мислех, че понеже Дез вероятно ще продължи с действителните техники и военните истории за отстраняването на грешки, реших, че просто ще направя обсъждане на фона, така че да получим напълно закръглена картина на случващото се. Правих това дълго време и бях кодер, така че е все едно и почти бях изкушен с тази презентация да започна да восъчна лирика за идеята за отворен код, но реших, че ще оставя това на някой друг.
Ето списък с известни бъгове и повечето от тях попадат в горния списък на никого, като цяло всички, с изключение на последните две, струват най-малко 100 милиона долара. Първият беше климатичният орбитър на Марс, изгуби се в космоса и се дължи на проблем с кодирането, при който хората объркаха метричните единици с (смее се) крака и инчове. В Ariane Five Flight 501 имаше несъответствие между двигател, който беше пуснат, и компютрите, които трябваше да управляват ракетата при изстрелването му. Множество компютърни повреди, взривяване на ракета, новини от заглавието. Съветският газопровод през 1982 г., за който се казва, че е най-голямата експлозия в историята на планетата; Не съм сигурен дали е така. Руснаците откраднаха някакъв автоматизиран софтуер за управление, а ЦРУ разбра, че ще го направят и сложи грешки в него, а Съветите го внедриха без тестване. И така, издух тръбопровод, мислех, че това е забавно.
Червеят Морис беше кодиращ експеримент, който изведнъж се превърна в разюздан червей, който обиколи всички - очевидно причини щети на стойност 100 милиона долара; това е приблизителна оценка. Intel направи известна грешка с математически чип - инструкция по математика за чипа Pentium през 1993 г. - която трябваше да струва над 100 милиона долара. Програмата на Google Maps е вероятно най-лошото и най-катастрофално стартиране на всичко, което Apple е правил някога. Хората, които се опитаха да го използват, искам да кажа, някой шофираше по 101 и откриха, че Apple Map казва, че са в средата на залива Сан Франциско. Така че хората започнаха да наричат приложението на Apple Maps като iLost. Най-дългият прекъсване през 1990 г. - това е интересно от гледна точка на цената на нещо подобно - AT&T са били извън девет часа и струват около 60 милиона долара при междуградски разговори.
И аз бях в застрахователна компания във Великобритания и базата данни, те внедриха нова версия на базата данни и тя започна да изтрива данни. И това си спомням изключително добре, защото след това бях повикан да участвам в някакъв вид избор на база данни заради това. И беше много интересно, че бяха взели нова версия на базата данни и имаха батерия от тестове, които направиха за нови версии на базата данни, че тя премина всички тестове. Той намери наистина неясен начин за изтриване на данни.
Така че, така или иначе, това е това. Мислех, че ще говоря за несъответствието на импеданса и издадения SQL. Интересно е, че релационните бази данни съхраняват данни в таблици и кодери са склонни да манипулират данни в структурите на обектите, които наистина не се преобразуват много добре в таблиците. И поради това вие получавате това, което се нарича несъответствие на импеданса и някой трябва да се справи с него по някакъв или друг начин. Но какво всъщност се случва, защото един модел, моделът на кодера и друг модел на базата данни, не са особено подравнени. Получавате грешки, които просто нямаше да се случат, ако индустрията беше изградила неща, които работят заедно, което според мен е смешно. Така че, по принцип, от страна на кодерите, когато получите йерархии, това може да бъде типове, може да доведе до набори, може да е лоша API способност, може да бъде много неща, които просто изхвърлят нещата от гледна точка на взаимодействие с базата данни. Но нещото, което е най-много за мен, наистина интересно; винаги ме учудваше, че сте имали тази SQL бариера, която също е един вид импеданс по начин, който кодерите и базата данни работят един с друг. Така че, SQL има разпознаване на данни, което е добре и има DML за подбор, проектиране и присъединяване, което е добре. Можете да хвърлите много възможности по отношение на извличане на данни от базата данни с това. Но той има много малко математически език за правене на неща. Има малко от това и това, и има много малко неща, базирани на времето. И поради това SQL е несъвършено, ако искате, средство за получаване на данните. Така че, момчетата от базата данни изградиха съхранени процедури, за да живеят в базата данни, а причината за съхраняваните процедури, живеещи там, беше, че всъщност не искате да хвърляте данни напред и назад в програма.
За някои функционалността беше изключително специфична за данните, така че не беше просто референтен интегритет и каскадни изтривания и подобни неща, базата данни се грижеше за внезапното влагане на функционалност в база данни, което разбираше, че функционалността на приложение може да бъде разделена между кодера и самата база данни. И това направи работата по внедряването на някои видове функции наистина доста трудна и следователно по-предразположена към грешки. Това е едната страна на играта с база данни, тъй като това означава, че имате много реализации, например, че съм участвал в релационни бази данни, има наистина много код, който се намира в съхранените процедури, които се обработват отделно от код, който се намира в приложенията. И изглежда като много странно нещо, което трябва да се получи, трябва да е доста умно да правиш различни неща.
Мислех, че ще говоря и за производителността на базата данни, тъй като грешките в производителността често се считат за грешки, но по принцип можете да имате затруднение в процесора, в паметта, на диска, в мрежата и можете да имате проблеми с производителността поради заключване, Идеята е, че кодерът всъщност не трябва да се тревожи за производителността и базата данни в действителност ще се представи доста добре. Предполага се, че кодерът няма нужда да знае. Въпреки това получавате лош дизайн на база данни, получавате лош дизайн на програмата, получавате едновременност в смесването на натоварването, което също може да доведе до проблеми с производителността. Получавате балансиране на натоварването, получавате планиране на капацитета, нарастване на данните - това може да доведе до спиране на базата данни или забавяне. Интересно е, когато базите данни се напълнят почти, те се забавят. И можете да имате проблем със слоевете данни по отношение на репликацията и необходимостта от репликация и необходимостта да направите архивиране и възстановяване. Както и да е, това е общ преглед.
Единственото нещо, което бих искал да кажа е, че отстраняването на грешки в базата данни може да бъде само толкова натоварващо и нетривиално - и казвам това, тъй като съм направил много от него - и често ще откриете, че е като всички ситуации при отстраняване на грешки, които аз някога изпитано е, първото нещо, което някога виждаш, е бъркотия. И трябва да опитате и да преминете от кашата, за да разберете как е възникнала кашата. И често когато гледате проблем с базата данни, всичко, което гледате, са повредени данни и си мислите: „Как, по дяволите, се случи това?“
Както и да е, ще предам на Дез, който вероятно ще каже повече думи на мъдрост, отколкото излязох. Не знам как да ти предам топката, Дез.
Ерик Кавана: Ще го предам, заставам настрана, задръжте.
Автоматизиран глас: линиите на участника са заглушени.
Ерик Кавана: Добре, задръжте една секунда, нека да дам топката на Дез.
Дез Бланчфийлд: Благодаря ти, Ерик. Да, д-р Робин Блур, вие наистина сте най-коректни: това е тема, бъг за цял живот, ако ще помилвате за каламбура, съжалявам, че не можах да се справя с него. Надявам се, че можете да видите първия ми екран там, моите извинения за проблема с размера на шрифта в горната част. Темата за бъговете е ежедневна лекция, в много случаи от моя опит. Това е толкова широка и широка тема, така че ще поставя фокуса върху две ключови области, по-специално върху концепцията за това, което считаме за много грешка, но проблем с програмирането. Мисля, че тези дни въвеждането на грешка сама по себе си по принцип се вдига от интегрираната среда за разработка, въпреки че може да са дългогодишни бъгове. Но често това е по-скоро случаят с профилиране на код и е възможно да се напише код, който функционира, това трябва да е грешка. И така, слайдът ми заглавие тук, аз всъщност имах копие от това в много висока резолюция A3, но за съжаление той се разруши при ход на къща. Но това е ръкописна бележка на лист за програмиране от около 1945 г., където уж някои хора от Харвардския университет в САЩ, втората им конструкция на машина, наречена Марк II. Отстраняват грешката по някакъв проблем, на общ език, но се опитват да намерят грешка и се оказва, че се случи нещо малко по-различно от това, което беше хардуер и предполагаемо софтуерно издание.
И така, градският мит е, че около 9 септември 1945 г. екип от Харвардския университет разцепва една машина, те се натъкват на нещо, което наричат "релейни седемдесет" - в онези дни програмирането се извършва във физически смисъл, вие навивате код около платка и така ефективно програмирате машината - и те откриха това реле номер седемдесет, че има нещо нередно с него и се оказва, че действителният термин „бъг“ се е появил, защото той буквално е бил молец - уж там беше молец, вклинен между някакво парче медна тел, преминаващо от едно място на друго. И историята отива, че легендарната Grace Hopper като тази надпис, за моя заглавие слайд, "първият действителен случай на грешка е намерена" цитирам цитат.
Но както Робин подчерта по-рано в първия си слайд, понятието за грешка отива толкова назад, колкото можем да си представим, че хората правят изчисления, понятия като кръпка. Терминът "кръпка" идва от действително парче лента, залепена върху дупка на перфокарта. Но целият смисъл на това е, че терминът "отстраняване на грешки" излезе от тази концепция за намиране на грешка във физическа машина. И оттогава ние използваме тази терминология около опит да се справим с проблеми, или не толкова като проблеми с кодирането в програма, която не се компилира, а като програма, която не работи добре. И конкретно не е профилиран, просто намерете неща като безкрайни контури, които просто не отиват никъде.
Но ние също имаме сценарий и мислех, че ще сложа няколко забавни слайда, преди да навляза малко по-подробно. Ето класическия анимационен филм, наречен XKCD в мрежата, а карикатуристът има някои доста смешни гледки към света. И това е за дете, наречено „Малки боби маси“ и уж родителите му са кръстили това младо момче Робърт “); ПУСКЕТЕ ТАБЛИЦА Ученици; - и се нарича, и нещо като "Здравей, това е училището на твоя син има някакви компютърни проблеми", а родителят отговаря: "О, скъпи, той ли е счупил нещо?" И учителят казва: "Е, по някакъв начин - и учителят пита: „Наистина ли кръстихте сина си Робърт“); СВЪРЗВАЙТЕ ТАБЛИЦА Ученици; -? ”А родителят казва:„ О, да, малки Боби Маси, ние го наричаме. И отговорът е: „Е, трябва да почистите и дезинфекцирате входовете на вашата база данни.“ И аз използвам това много пъти, за да говоря за някои от проблемите, които имаме при намирането на неща в кода, че често кодът не разглежда данните също.
Друг забавен, не знам дали това е истинско или не - подозирам, че е измама - но отново, той докосва и смешната ми кост. Някой, който сменя регистрационния номер на предната част на колата си, на подобно твърдение, което причинява спад на базите данни в камерите за скорост и т.н., които заснемат регистрационните табели на автомобилите. И винаги го отнасям като това, че се съмнявам, че всеки програмист е очаквал хит и изпълнение на техния код от действително моторно превозно средство, но никога не е за подценяване - сила на гневен маниер.
(Смях)
Но това ме води до моя ключов момент, предполагам, и това е, че веднъж време бихме могли да отстраняваме грешки и да кодираме профила като простосмъртни. Но аз съм много на мнението, че това време е минало и анекдотично в моя опит, първият ми - и това ще ме остарее ужасно, сигурен съм; Робин, ти си добре дошъл да ми се забавляваш заради това - но в исторически план съм дошъл от фона на 14-годишна възраст, скитайки по края на града и чукайки на вратата на център за данни, наречен „Data Com” в Ню Зеландия и питам дали мога да печеля джобни пари в училището, като се прибирам в късния автобус до вкъщи, около 25 км пътуване всеки ден, като поставям хартия в принтери и касети в касети и просто съм генерален администратор. И достатъчно любопитно са ми дали работа. Но с времето успях да вляза в персонала и да намеря програмистите и разбрах, че обичам кодирането и преминах през процеса на изпълнение на скриптове и пакетни задачи, който в края на деня все още е код. Трябва да напишете скриптове и партидни задачи, които приличат на мини програми и след това да преминете през целия процес на седене на 3270 код за писане на терминал на ръка.
Всъщност първото ми преживяване беше на терминал за телетипи, който всъщност беше 132-колонен физически принтер. По същество, помислете за много стара пишеща машина с хартия, която се превърта през нея, защото те нямаха CRT тръба. И отстраняването на грешки в този код беше много нетривиален проблем, така че вие сте склонни да напишете целия си код на ръка и след това да се държите като машинописка, като правите всичко възможно да не получавате грешки, за да се промъкнете, защото е изключително неприятно да се налага да кажете един ред редактор, за да отидете на определен ред и след това да отпечатате реда и след това да го въведете отново. Но веднъж по този начин написахме код и така се отстраниха грешки, и получихме много, много добри в него. И всъщност ни принуди да имаме много добри техники за програмиране, защото беше истинска кавга да го поправим. Но след това пътуването премина - и всички сме запознати с това - премина от преживяването на терминала 3270 в моя свят, до Digital Equipment VT220, където можете да видите нещата на екрана, но отново, просто правехте същото направихте на хартиената лента нещо като отпечатан формат само на CRT, но вие бяхте в състояние да изтриете по-лесно и нямате този звук „dit dit dit dit“.
И тогава знаете, терминалите Wyse - като Wyse 150 - вероятно любимият ми интерфейс към компютър някога - и след това към компютъра, а след това към Mac, а в наши дни модерни GUI и ID, които са базирани в мрежата. И редица програми чрез това, програмиране в едно и асемблер и PILOT и лого, Lisp и, Fortran и Pascal и езици, които могат да накарат хората да се гърчат. Но това са езици, които ви принудиха да пишете добър код; не ви позволиха да се измъкнете с лоши практики. C, C ++, Java, Ruby, Python - и стигаме по-нататък до този етап на програмиране, получаваме повече подобни на скрипт, се приближаваме и се доближаваме до Structured Query Language и езици като PHP, които всъщност се използват за извикване на SQL. Смисълът да ви кажа, че идва от моя произход, аз бях самоук по много начини и тези, които ми помогнаха да се уча, научиха ме на много добри практики в програмирането и много добри практики около дизайна и процесите, за да съм сигурен, че не съм го направил въведете бъги код.
Методи за програмиране в наши дни, като например, Structured Query Language, SQL, това е много мощен, прост език за заявки. Но ние го превърнахме в език за програмиране и всъщност не вярвам, че SQL някога е бил създаден като модерен език за програмиране, но сме го изкривили, за да стане това. И това въвежда цял куп проблеми, защото когато мислим за това от две гледни точки: от гледна точка на кодиране и от гледна точка на DBA. Много е лесно да се съберат и да се въведат грешки за неща като просто лоши техники за програмиране, мързеливи усилия при писане на код, липса на опит, класическият домашен любимец, който имам, например със SQL хора, които скачат в Google и търсят нещо и намират уебсайт, който е имам пример и правим копие и паста на съществуващ код. И след това да репликирате лошо кодиране, злоупотреба и да го пуснете в производство, защото просто се случва да им дадете желаните от тях резултати. Имате други предизвикателства, например, в наши дни всички ние се втурваме към това, онова, което наричаме състезанието до нула: опитваме се да направим всичко толкова евтино и толкова бързо, че имаме сценарий, при който не използваме по-ниски -платен персонал. И не искам да кажа това по небрежен начин, но не наемаме експерти за всяка възможна работа. Някога всичко, свързано с компютрите, беше ракетната наука; тя беше замесена във неща, които се втурнаха и бяха много силни, или влязоха в космоса, или инженерите бяха висококвалифицирани мъже и жени, които бяха завършили образователни степени и строги образования, които ги предпазваха да правят безумни неща.
В наши дни има много хора, които се занимават с разработка и дизайн и база данни, които не са имали години опит, не са имали непременно същото обучение или подкрепа. И така завършвате със сценарий само на традиционния аматьор срещу експерт. И има една известна линия, всъщност не мога да си спомня кой е създал цитата, следният текст гласи: „Ако смятате, че е скъпо да наемете експерт, който да свърши работа, изчакайте, докато наемете няколко аматьори, които създават проблем и вие трябва да го почистите. "И така SQL има този проблем и е много, много лесно да се учи, много е лесен за използване. Но според мен не е перфектен език за програмиране. Много е лесно да правите неща като правите избрана звезда от където и да е и да издърпате всичко това на език за програмиране, с който сте по-удобни като PHP и Ruby или Python, и да използвате езика за програмиране, с когото сте запознати, да правите манипулирането на данни, вместо да се извършва по-сложна заявка в SQL. И ние виждаме това много и тогава хората се чудят защо базата данни работи бавно; това е така, защото милион души се опитват да купят билет от онлайн система за билети, където прави избрана звезда отвсякъде.
Това е наистина екстремен пример, но вие разбирате всичко от всичко това. И така, за да удрям наистина тази точка у дома, ето един пример, който нося много. Аз съм голям фен на математиката, обичам теорията на хаоса, обичам комплектите на Манделброт. От дясната страна има предаване на набора Mandelbrot, с което съм сигурен, че всички сме запознати. И отляво има парче SQL, което всъщност прави това. Сега, всеки път, когато поставям това на екран някъде, чувам това „О, боже мой, някой е направил серията Mandelbrot със SQL, сериозен ли си? Това е безумно! ”Е, целият смисъл на това е да илюстрирам какво точно очертах там и това е да, всъщност вече можете да програмирате почти всичко в SQL; това е много силно развит, мощен, модерен език за програмиране. Когато първоначално това е бил език за запитвания, той е създаден така, че просто да получи данни. И така, сега имаме много сложни конструкции и съхраняваме съхранени процедури, прилагаме методология на програмиране на език и така е много лесно за лоша практика на програмиране, липса на опит, код за изрязване и поставяне, нископлатен персонал, който се опитва да бъде високоплатен персонал, хора се преструват, че знаят, но трябва да се учат на работата.
Цяла гама от неща, при които профилирането на кодове и това, което ние наричаме отстраняване на грешки, е не толкова намирането на грешки, които спират програмите да работят, а грешките, които просто нараняват системата и лошо структурирания код. Когато погледнете този екран сега и мислите, че това е просто, това е някак си сладко и си мислите: „Леле, каква страхотна графика, бих се радвал да стартирам това.“ Но си представете, че работи по някаква част от бизнес логиката, Изглежда доста кокетно, но говори математически графично представена теория на хаоса, но когато се замислите за какво би могло да се използва в някаква бизнес логика, вие получавате картината много бързо. И наистина да илюстрирам това - и съжалявам, че цветовете са обърнати, трябва да е черен фон и зелен текст, за да бъде зелен екран, но все пак можете да прочетете това.
Отидох и разгледах набързо пример за това, което потенциално бихте могли да направите, ако сте наистина луд и нямате никакъв опит и идвах от различен фон на програмиране и прилагах харесванията на C ++ в SQL, за да илюстрирам моята точка, преди Предавам на нашия учен гост от IDERA. Това е структурирана заявка, която е написана като C ++, но е кодирана в SQL. И всъщност се изпълнява, но се изпълнява за около три до пет минути. И тя дърпа назад сякаш един ред данни от множество бази данни, множество съединения.
Отново, целият смисъл на това е, че ако нямате правилните инструменти, ако нямате правилните платформи и среди, за да можете да уловите тези неща, и те да влязат в производство, и тогава имате 100 000 души удряйки система всеки ден, час или минута, много скоро приключвате с преживяването в Чернобил, при което голямото желязо започва да се стопява и заравя в сърцевината на планетата, защото това парче код никога не бива да влиза в производство. Вашите системи и вашите инструменти, извинете ме, трябва да го вземете, преди да стигне до никъде в близост - дори и през процеса на тестване, дори чрез UAT и интеграция на системи, това парче код трябва да се вземе и подчертае, а някой да бъде оставен настрана и казвайки: „Вижте, това е наистина доста код, но нека да вземем DBA, за да ви помогнем да изградите правилно тази структурирана заявка, защото честно казано, това е просто гадно.“ И URL адресът е там, можете да отидете и да погледнете - това се нарича най-сложната SQL заявка, която някога сте писали. Защото повярвайте ми, че всъщност се компилира, той работи. И ако изрежете и поставите това и просто се подигравате с базата данни, е нещо, което трябва да гледате; ако имате инструментите за гледане на базата данни, просто опитайте да се стопите за период от три до пет минути, за да се обадите обратно какъв е един ред текст.
Така че, да обобщя, имайки предвид това, целият ми опит в кодирането ме научи, че можете да дадете на хората пистолет и ако не внимават, те ще се стрелят в крака; трикът е да им покажете къде е механизмът за безопасност. С правилните инструменти и подходящия софтуер на една ръка разстояние, след като направите кодирането, можете да прегледате кода си, можете да намерите проблеми чрез профилиране на кода, можете да намерите ефективно нежелани грешки, които са проблеми с производителността и както казах по-рано, веднъж, можете да го направите, гледайки зелен екран. Не можеш повече; има стотици хиляди редове с код, има десетки хиляди приложения, в някои случаи има милиони бази данни и дори супер хора всъщност не могат да правят това на ръка вече. Вие буквално се нуждаете от правилния софтуер и правилните инструменти под ръка и се нуждаете от екипа, който да използва тези инструменти, така че да можете да намерите тези проблеми и да ги адресирате много, много бързо, преди да стигнете дотам, докато Dr. Робин Блур подчерта, че нещата стават катастрофални и нещата се взривяват, или по-често, те просто започват да ви струват много долари и много време и усилия и унищожават морала и други неща, когато не могат да разберат защо нещата отнемат дълго време да тичам.
Имайки предвид това, ще предам на нашия гост и с нетърпение очаквам да чуя как са решили този въпрос. И по-специално демонстрацията, която мисля, че предстои да получим. Ерик, ще мина отново.
Ерик Кавана: Добре, Берт, отнеси го.
Берт Скалцо: Добре, благодаря. Bert Scalzo тук от IDERA, аз съм продуктовият мениджър за нашите инструменти за бази данни. И ще говоря за отстраняване на грешки. Мисля, че едно от най-важните неща, което Робин каза по-рано - и това е много вярно, е, че отстраняването на грешки е натоварващо и нетривиално, а когато отидете на отстраняване на грешки в базата данни, е порядък с още по-тежка и нетривиална - така че, беше важен цитат.
ДОБРЕ. Исках да започна с историята на програмирането, защото много пъти виждам хора, които не отстраняват грешки, не използват дебъгер, просто програмират с какъвто и език да използват и много пъти ще ми кажат, „Е, тези неща за отстраняване на грешки са нови, а ние още не сме започнали да ги използваме.“ И така, което правя, е да им покажа тази диаграма на времевата линия, нещо като предистория, старост, среден век, това е вид да кажем къде бяхме по отношение на програмните езици. И имахме много стари езици, започващи през 1951 г. с код за сглобяване, и Lisp, и FACT и COBOL. След това влизаме в следващата група, Pascals и Cs и след това следващата група, C ++ s, и поглеждаме къде е въпросният знак - въпросният знак е приблизително точно около 1978 до може би 1980 г. Някъде в този диапазон имахме дебъггери, достъпни за нас, и така да се каже: „Ей, аз не използвам грешка, защото това е едно от онези нови неща“, тогава сигурно сте започнали да програмирате, знаете, през 50-те години на миналия век, защото това е единственият начин да се измъкнете с това искане.
Сега другото, което е смешно в тази диаграма е Дез току-що направи коментар за Грейс Хопър, всъщност познавах Грейс, така че е някак смешно. И тогава другото, на което се засмях, е, че той говори за телетипи и аз седя там и вървя: „Човече, това беше най-големият скок, който някога сме имали в производителността, когато преминавахме от карти към телетипове, това беше най-големият скок досега. „И така, аз програмирах на всички езици тук, включително SNOBOL, за който никой досега не е чувал, това е CDC, Control Data Corporation, така че предполагам, че съм прекалено стар за тази индустрия,
Дез Бланчфийлд: Щях да кажа, че сте ни остаряли ужасно.
Берт Скалцо: Да, казвам ви, чувствам се като дядо Симпсън. Затова разглеждам отстраняване на грешки и има различни начини за извършване на грешки. Бихте могли да говорите за това, което всички ние смятаме за традиционно влизане в отстраняване на грешки и преминаване през код. Но също така хората ще инструментират своя код; ето там вие залепвате изявления във вашия код и може би създавате изходен файл, файл със следи или нещо подобно и така инструментирате кода си. Бих считал, че като отстраняване на грешки, това е малко по-трудно, начин да го направите, но се отчита. Но също така имаме известното изявление за печат: наблюдавате и хората всъщност поставят отчети за печат и всъщност видях инструмент, където - и това е инструмент за база данни - където, ако не знаете как да използвате грешка, натискате бутон и той ще залепи изявления за печат в целия код за вас и след това, когато сте готови, натиснете друг бутон и той ще ги изтрие. Защото по този начин много хора отстраняват грешки.
И причината за отстраняването на грешки е двойна: на първо място трябва да намерим неща, които правят кода ни неефективен. С други думи, обикновено това означава, че има логическа грешка или сме пропуснали бизнес изискване, но какво е, кодът не е ефективен; тя не прави това, което очаквахме. Другия път, когато вървим и отстраняваме грешки, това е за ефективност и това може да е логическа грешка, но какво е, направих ли правилното нещо, просто не се връща достатъчно бързо. Сега, подчертавам това, защото профила вероятно е по-добър за втория сценарий и ще говорим както за отстраняване на грешки, така и за профили. В допълнение, има тази концепция за отдалечено отстраняване на грешки; това е важно, защото много пъти, ако седите на личния си компютър и използвате грешка, която удря база данни, където кодът всъщност се изпълнява в базата данни, всъщност правите това, което се нарича отдалечено отстраняване на грешки. Може да не го осъзнаете, но това се случва. И тогава е много често при тези грешки да има точки на почивка, точки за гледане, стъпка и пристъпване и някои други често срещани неща, които ще ги покажа на моментна снимка на екрана.
Сега, профилиране: можете да направите профилиране по няколко различни начина. Някои хора ще кажат, че заснемането и повторното натоварване на работното място, където заснема всичко, това се счита за профилиране. Моят опит е повече, по-добре е, ако се прави проба. Няма причина да хващате всяко едно изявление, защото някои изявления може просто да стартират толкова бързо, че не ви пука, това, което наистина се опитвате да видите, е, кои са тези, които продължават да се показват отново и отново, защото те вървят твърде дълго. Така че понякога профилирането може да означава вземане на проби, а не изпълнение на цялата работа. И обикновено ще получите някакъв изход, който можете да използвате, сега това би могло да бъде визуално в среда за разработка на IDE, където може да ви даде като хистограма на производителността на различните редове от код, но може и все още бъде, че произвежда файл с следи.
Профилите се появяват за първи път през 1979 г. И така, те също са отдавна. Чудесно за намиране на потреблението на ресурси или проблеми с производителността, с други думи, това е ефективност. Най-общо казано, той е отделен и различен от отстраняването на грешки, въпреки че съм работил с отстраняване на грешки, които правят и двете едновременно. И докато профилите мисля, че са по-интересните от двата инструмента, ако почувствам, че няма достатъчно проблеми за отстраняване на грешки, тогава определено няма достатъчно хора профили, защото един от десет дебъгъра ще профилира, изглежда. И това е жалко, защото профилирането наистина може да доведе до огромна промяна. Сега, езици на базата данни, както говорихме по-рано, имате SQL - и ние някак си принудихме кръглото забиване в квадратната дупка тук и го принудихме да се превърне в език за програмиране - и Oracle. Това е PL / SQL - това е процедурен език SQL - и SQL Server, това е Transact-SQL, това е SQL-99, това е SQL / PSM - за, мисля, че е модул за процедурата се съхранява. Postgres му дава друго име, DB2 още едно име, Informix, но въпросът е, че всеки е принудил 3GL тип конструкции; с други думи, FOR цикли, при декларации с променлива и всички други неща, които са чужди на SQL, вече са част от SQL на тези езици. И така, трябва да можете да отстранявате грешки в PL / SQL или Transact-SQL, точно както бихте направили Visual Basic програма.
Сега, обекти на базата данни, това е важно, защото хората ще кажат: „Е, какви неща трябва да отстранявам в грешка в база данни?“ И отговорът е, добре, каквото можеш да съхраняваш в базата данни като код - ако правя T-SQL или PL / SQL - и съхранявам обекти в базата данни, това вероятно е съхранена процедура или съхранена функция. Но има и тригери: тригерът е нещо като съхранена процедура, но се задейства на някакъв вид събитие. Сега някои хора в своите задействания ще поставят един ред код и ще извикат запаметена процедура, така че да запазят целия си съхранен код и процедури, но това е същата концепция: все още спусъкът може да бъде това, което инициира цялата работа. И тогава като Oracle, те имат нещо наречено пакет, което е нещо като библиотека, ако щете. Вие поставяте 50 или 100 съхранени процедури в едно групиране, наречено пакет, така че това е нещо като библиотека. И така, ето отстраняването на грешки по стария начин; това всъщност е инструмент, който всъщност ще влезе и ще залепи всички тези изявления за отстраняване на грешки във вашия код за вас. Така че, навсякъде, където виждате блок за отстраняване на грешки, не премахвайте, стартирането и проследяването на автоматично отстраняване на грешки, всички те бяха заседнали от някакъв инструмент. И линиите извън това, което е малцинството на кода, е, това е методът за отстраняване на грешки, който не е ръчен.
И причината да изложа това е, че ако се опитвате да направите това на ръка, всъщност ще въведете повече код за отстраняване на грешки, който ще поставите във всички тези изявления за печат, отколкото сте с кода. И така, макар че това може да работи и макар да е по-добре от нищо, това е много труден начин за отстраняване на грешки, особено тъй като какво ще стане, ако са нужни 10 часа, за да стартира това нещо и къде има проблем, е в ред три? Ако правих интерактивна сесия за отстраняване на грешки, щях да знам на линия три - пет минути в нея - ей, тук има проблем, мога да прекратя. Но с това трябва да изчакам да стартира, чак до завършване и след това трябва да погледна някакъв файл със следи, който вероятно има всички тези изявления за печат в него, и да опитам да намеря иглата в купа сено. Отново това е по-добре от нищо, но не би било най-добрият начин за работа. Ето, този файл ще изглежда така, че идва от предишния слайд; с други думи, аз стартирах програмата и тя просто има куп изявления за печат в този файл с проследяване и мога или не мога да успея да пресичам това и да намеря това, което трябва да намеря. И така, отново не съм толкова сигурен, че това е начинът, по който бихте искали да работите.
Сега, интерактивни грешки - и ако сте използвали нещо като Visual Studio за писане на програми или Eclipse, сте имали грешки и сте ги използвали с други ваши езици - просто не мислех да ги използвам тук с вашата база данни. И там има инструменти, като нашия DB Artisan и нашия Rapid SQL, тук е Rapid SQL, който има отстраняване на грешки и можете да видите отляво, имам запаметена процедура, наречена „провери за дубликати“. По принцип просто ще отида да погледна и ще видя дали имам няколко реда в таблицата със същото заглавие на филма. Така че, базата данни е за филми. И можете да видите от дясната страна, в горната трета, в средата си имам изходния си код, имам така наречените променливи на часовника си и таблиците си за стек на повикване, а след това в долната част аз ' имам няколко изходни съобщения. И това, което е важно тук, е, ако погледнете тази първа червена стрелка, ако мишката върху променлива, всъщност мога да видя каква стойност е в тази променлива в този момент, докато преглеждам кода. И това е наистина полезно и тогава мога да стъпвам по един ред наведнъж през кода, не трябва да казвам Execute, бих могъл да кажа стъпка линия, нека да видя какво се случи, стъпка друг ред, нека да видя какво се е случило, и аз правя това в базата данни. И въпреки че аз седя на Rapid SQL на моя компютър и моята база данни е в облака, все още мога да направя това отдалечено отстраняване на грешки и да го видя и да го контролирам от тук, и да правя отстраняване на грешки точно както бих направил с всеки друг език.
Сега следващата стрелка там - можете да видите малката като стрелка, сочеща надясно, към този изход на СУБД, там е моят курсор в момента - така че с други думи, аз съм стъпил и там съм на момента. Така че, ако кажа: „Стъпка отново“, ще премина към следващия ред. Сега точно под това ще видите червената точка. Е, това е точка на прекъсване, която казва „Ей, не искам да преминавам през тези редове.“ Ако просто искам да прескоча всичко и да стигна до мястото, където е тази червена точка, мога да натисна бутона за стартиране и той ще се задейства от тук или до края, или до точка на прекъсване, ако има поставени някакви точки на прекъсване и тогава тя ще спре и ме остави да направя стъпването отново. И причината, че всичко това е важно и е мощно, е, че когато правя всичко това, това, което се случва в средата и дори отдолу - но най-важното е средата - ще се промени и мога да видя стойностите от променливите си, Виждам следа от стека на обажданията, знаете, и така цялата тази информация се показва там, докато преглеждам кода, така че всъщност мога да видя и усетя и да разбера какво се случва и как всъщност е кодът работещи по време на изпълнение. И обикновено мога да намеря проблем, ако има такъв или ако съм достатъчно добър, за да го уловя.
Добре, сега ще говоря за профилер и в случая това е профилер, който мога да видя чрез отстраняване на грешки. Спомняте ли си, че казах, че понякога са разделени, а понякога могат да бъдат заедно? В този случай и отново съм в Rapid SQL и виждам, че отляво до номерата на линията има поле отляво. И това, което е, това е броят секунди или микросекунди, необходими за изпълнение на всеки ред код и мога да видя това ясно, че цялото си време прекарвам в този един цикъл FOR, където избирам всичко от таблица, И така, каквото и да се случва вътре в този цикъл FOR, вероятно е нещо, което трябва да разгледам, и ако успея да го подобря, ще изплати дивиденти. Няма да получавам подобрения, като работя върху тези линии, които имат 0, 90 или 0, 86; няма много време прекарано там. В този случай и отново съм в Rapid SQL, виждате как мога да правя профилиране, смесено с моята грешка. Това, което е хубаво е, че Rapid SQL също ви позволява да го направите по друг начин. Rapid SQL ви позволява да кажете: „Знаеш ли какво? Не искам да бъда в грешката, просто искам да стартирам това и тогава искам да разгледам графично или визуално един и същ тип информация. "
И можете да видите, че вече не съм в отстраняването на грешки и тя изпълнява програмата и след като изпълнението е извършено, ми дава диаграми да ми казва нещата, така че да видя, че имам едно изявление, което изглежда сякаш заема по-голямата част от диаграмата на пай и ако гледам, виждам на тази решетка към дъното, линия 23, отново е веригата FOR: той поема най-много време, той всъщност е тъмночервен дъвчещ цялата диаграма на пай. И така, това е друг начин за правене на профили. Случва се да наричаме този „анализатор на код“ в нашия инструмент. Но всъщност е просто профилер, отделен от грешка. Някои хора обичат да го правят по първия начин, някои хора обичат да го правят по втория начин.
Защо правим отстраняване на грешки и профилиране? Не защото искаме да напишем най-големия код в света и да получим заплащане - това може да е нашата причина, но всъщност това не е причината да го правите - обещахте на бизнеса, че ще направите нещо правилно, че вашата програма ще бъде ефективна. За това ще използвате дебъгъра. В допълнение, бизнес крайни потребители; не са много търпеливи: искат резултати дори преди да натиснат клавиша. Ние трябва да четем тяхното мнение и да правим всичко моментално. С други думи, това трябва да бъде ефективно. И така, за това бихме използвали профила. Сега, без тези инструменти, аз наистина вярвам, че сте този човек в бизнес костюма с лък и стрела и стреляте по целта и сте със завързани очи. Защото как ще откриете как дадена програма се изпълнява, само като погледнете статичния код и как ще разберете кой ред е къде наистина би прекарал най-много време в изпълнение, отново само като погледнете статичния код? Прегледът на код може или не може да доведе до някои от тези неща, но няма гаранция, че прегледът на кода ще ги намери всички. С помощта на грешка и профилер трябва да можете да намерите всички тези грешки.
Добре, просто ще направя истинска бърза демонстрация тук. Не ми е намерение да натискам продукт, просто искам да ви покажа как изглежда отстраняването на грешки, защото много пъти хората ще кажат: „Никога не съм виждал някое от тях преди.“ И изглежда доста на екрана за щракване на екрана, но как изглежда, когато е в движение? И така, тук на моя екран пускам нашия DB Artisan продукт; там също имаме грешка. DB Artisan е предназначен повече за DBA, Rapid SQL е повече за разработчиците, но съм виждал разработчици, които използват DB Artisan, и съм виждал DBA, които използват Rapid. Така че, не се хващайте за продукта. И ето, имам избор да правя грешка, но преди да стартирам грешката, ще извлека този код, за да можете да видите как изглежда кодът, преди да започна да го изпълнявам. И така, ето точно същият код, който беше в снимката на екрана, това е моята проверка за дубликати. И искам да отстраня грешката в това, затова натискам грешка. И сега отнема момент и вие казвате: „Е, защо ви отнема момент?“ Запомнете отдалеченото отстраняване на грешки: отстраняването на грешки всъщност се случва на моя сървър на база данни, а не на моя компютър. И така, тя трябваше да премине и да създаде сесия там, да създаде дистанционно отстраняване на грешки, да закача сесията ми към тази сесия за отдалечено отстраняване на грешки и да настрои комуникационен канал.
И така, ето моята стрелка, там е горе в горната част, от първия ред, там съм в кода. И ако натисна третата икона там, което е стъпка, ще видите, че стрелката просто се е преместила и ако продължа да я натискам, ще видите, че продължава да се движи. Сега, ако исках да стигна до този цикъл ЗА, защото знам, че там е проблемът, мога да определя точка на прекъсване. Мислех, че го настроя. О, снимайте, имах един от ключовете за заснемане на екрана, картографиран на същия ключ като дебъгъра, това е причината за объркването. ОК, така че просто ръчно зададох точка на прекъсване там, така че сега вместо да правя стъпка, стъпка, стъпка, стъпка, докато стигна до там, всъщност мога просто да кажа: „Напред и пусни това нещо“ и тя ще спре. Забележете, че ме премести чак до мястото, където е точката на прекъсване, така че сега съм в контекста на изпълнение на този цикъл, мога да видя на какво са зададени всичките ми променливи, което не е изненада, защото ги инициализирах всичките до нула. И сега мога да вляза в този цикъл и да започна да гледам какво се случва вътре в този цикъл.
И така, сега ще направя избран брой от моите наеми и мога да преместя с мишката върху този човек и да гледам, той е два, два е по-голям от един, така че вероятно ще направя следващото парче от този код. С други думи, тя намери нещо. Просто ще продължа напред и ще пусна това. Не искам да минавам през всичко тук; това, което искам да ви покажа е, когато се извършва отстраняване на грешки, той завършва точно като нормална програма. Имам зададена точка на прекъсване, така че когато казах, че бягам, просто се върна към следващата точка на прекъсване. Оставям го да работи докрай, защото това, което искам да видите е, че отстраняването на грешки не променя поведението на програмата: когато тя се изпълнява, трябва да получа същите резултати, ако я бях пуснал не вътре в грешка.
И с това ще прекратя демонстрацията и ще се върна, защото искаме да сме сигурни, че имаме време за въпроси и отговори. И така, ще го отворя за въпроси и отговори.
Ерик Кавана: Добре, Робин, може би въпрос от теб и после двойка от Дез?
Робин Блур: Да, разбира се, намирам това очарователно, разбира се. Работил съм с такива неща, но никога не съм работил с подобно нещо в базата данни. Можете ли да ми дадете някаква представа за какво хората използват профила? Тъй като е, гледат ли те - защото предполагам, че са - те разглеждат проблеми с производителността, дали ще ви помогне да разграничите кога базата данни отнема време и кода отнема време?
Берт Скалцо: Знаеш ли, това е фантастичен въпрос. Да речем, че работя във Visual Basic, а аз вътре в Visual Basic ще се обадя на Transact-SQL или PL / SQL. Нека да направя PL / SQL, тъй като Oracle не винаги играе добре с инструментите на Microsoft. Може да профилирам моя Visual Basic код и профилът там може да казва: „Ей, аз нарекох тази съхранена процедура и отне твърде много време.“ Но тогава мога да вляза в съхранената процедура и мога да направя профил на база данни на съхранения процедурата и кажете: „Добре, от 100-те изявления, които са тук, ето петте, които са причинили проблема.“ И така, може да се наложи да направите екип с тагове, където трябва да използвате множество профили.
Идеята е, че ако някога ви кажат, че проблемът с производителността е във вашата база данни, профилът в базата данни може да ви помогне да намерите иглата в сенокос, върху която всъщност са изявленията, в които имате проблем. Казвам ви още нещо, което се оказа с профилирането: ако имате парче код, който се извиква милион пъти, но отнема само микросекунда всеки милион пъти, но се нарича милион пъти, какво ще покаже профила, това нещо вървеше за това много единици време. И така, макар че кодът може да е високоефективен, може да погледнете и да кажете: „Ооо, ние отправяме този разговор по този начин на код много често. Може би трябва да го наричаме само толкова често, а не всеки път, когато обработваме запис “или нещо подобно. И така всъщност можете да намерите къде има ефективен код, който просто се нарича твърде често и това всъщност е проблем с производителността.
Робин Блур: Да, това е прекрасно. Никога не съм правил това. Разбирате, когато имах проблеми с базата данни, сякаш по един или друг начин се занимавах с база данни или се занимавам с код; Никога не бих могъл да се справя с двамата едновременно. Но там, отново, не съм направил - никога всъщност не съм участвал в изграждането на приложения, където имахме съхранени процедури, така че предполагам никога не съм срещал проблеми, които ме разяждаха, идеята, че вие щях да разделя кода между база данни и програма. Но така, направете всичко - предполагам, че отговорът ще бъде „да“, но това е част от дейността на екипа за развитие, когато по един или друг начин се опитвате да поправите нещо, което е счупено, или може би се опитвате да внесете ново приложение заедно. Но всичко това ли е съобразено с всички останали компоненти, които бих очаквал в околната среда? Мога ли да очаквам, че бих могъл да го клипирам заедно с всичките си тестови пакети и всички онези други неща, които бих правил и с моите неща за управление на проекти, ето как всички тези клипове са заедно?
Берт Скалцо: Да, това може да стане част от всеки структуриран процес, който да направи вашите усилия за програмиране или разработка. И смешно е, че миналата седмица имах клиент, който създаваше уеб приложение и тяхната база данни в историята беше малка и затова фактът, че не бяха много добри програмисти, никога не ги нараняваше. Е, тяхната база данни се разраства с годините и сега отнема 20 секунди в уеб страница, между когато казвате: „Влезте ми и ми дайте малко данни, за да видя“ и кога екранът действително се появи, и така сега е проблем с производителността. И знаеха, че проблемът не е в никоя от тяхната Java или някое от онези други места. Но те имаха хиляди съхранени процедури и затова трябваше да започнат профилиране на съхранените процедури, за да разберат защо тази уеб страница отнема 20 секунди? И всъщност установихме, че имат декартово присъединяване в едно от избраните от тях изявления и не го знаехме.
Robin Bloor: Леле.
Берт Скалцо: Но някой ми каза веднъж: „Е, как биха могли да се присъединят декартово и да не го знаят?“ И това ще звучи наистина ужасно; понякога програмист, който не е много удобен със SQL, ще направи нещо като да ми присъедини декартово, но след това само ще ми върне първия запис, така че знам, че имам нещо и имам нужда само от първия. И така, те не осъзнават, че те просто са върнали милиард записи или преглеждат милиард записи, защото са получили този, който ги е интересувал.
Робин Блур: Уау, знам, така се казва - е, точно това се случваше Дез по отношение на хора, които не са толкова умели, колкото може би трябва да са, нали знаеш. Ако сте програмист, трябва да знаете какви са последиците от издаването на която и да е команда. Искам да кажа, наистина няма оправдание за това ниво на глупост. Предполагам също, че по един или друг начин вие сте просто езиков агностик по отношение на това, защото всичко това е съсредоточено върху страната на базата данни. Прав ли съм в това? Дали е същото, каквото и да използвате от кодиращата страна?
Bert Scalzo: Абсолютно можете да направите това във Fortran или C или C ++. Всъщност, в някои Unixes дори можете да го направите за техните скриптови езици; те всъщност предоставят същите инструменти. И тогава искам да се върна секунда за това, което казахте без извинение. Ще направя една почивка на програмистите, защото не обичам да хвърлям програмисти под автобуса. Но проблемът наистина е академичната среда, защото когато отидете да научите как да бъдете програмист, вие сте научени да мислите записващо по време. Не сте научени да задавате мислене и това е това, което Structured Query Language или SQL работи с набори; затова имаме обединението, пресечната точка и оператора минус. И понякога е много трудно човек, който никога не е мислил по отношение на комплекти, да се откаже, да пусне обработка на записи по време и да работи с набори.
Робин Блур: Да, аз съм с теб по въпроса. Искам да кажа, че разбирам сега, това е проблем с образованието; Мисля, че това е напълно проблем на образованието, мисля, че е естествено програмистите да мислят процедурно. И SQL не е процедурен, а е декларативен. Всъщност просто казвате: „Това искам и не ме интересува как го правите“, нали знаете? Като имате предвид, че с езиците за програмиране често запретвате ръкави и вие сте в подробности дори да управлявате броя, докато правите цикъл. Ще предам на …
Берт Скалцо: Не. ОК, продължи.
Да, исках да кажа, че вие представихте още един пример, че един профилер би бил добър за хващане, като това продължава с тази запис в момента. Понякога програмист, който има добра логика на запис, не може да разбере как да прави SQL програма. Е, да кажем, че прави два цикъла FOR и по принцип прави съединение, но го прави от страна на клиента. Така че, той прави същия ефект като присъединяването, но той го прави сам и един профил ще улови това, защото най-вероятно ще свършите повече време за свързване ръчно, отколкото да оставите сървъра на базата данни да го направи вместо вас.
Робин Блур: Да, това би било катастрофа. Искам да кажа, че просто бихте мъркали. Тракането винаги е лошо.
Както и да е, ще предам на Дез; Сигурен съм, че има интересни въпроси.
Дез Бланчфийлд: Благодаря, да, да. Ще се присъединя към вас в не хвърлянето на програмисти под автобуса. Искам да кажа, че прекарах много години в живота си да бъда кодер на всяко ниво, нали знаете, независимо дали казахте, седейки в командния ред на Unix машината, а в някои случаи дори бях замесен в няколко различни пристанища на Unix от една хардуерна платформа до друга. И можете да си представите предизвикателствата, които имахме там. Но реалността е ето тази карта за излизане от затвора за всеки кодер и сценарист в света. Ракетна наука, съвсем буквално, всеки път да пишеш наистина здраво, през цялото време е ракетна наука. И известни истории на хора като Денис Ричи и Брайън Кернахан, които работят върху някакъв код независимо и след това се обръщат към чат за преглед на кодове по кафе и установяват, че са написали точно същия код в точно същата програма, по абсолютно същия начин. И го направиха в C. Но това пуристично ниво на програмиране съществува много рядко.
Факт е, че ежедневно има само 24 часа на ден, седем дни в седмицата и просто трябва да свършим нещата. И така, що се отнася до не само традиционните програмисти, DBA, и кодери, и скриптове, и sysadmin, и мрежови администратори, и служители по сигурността, и всичко до края на данните за гражданите в наши дни; чуваме, всеки просто се опитва да си свърши работата. И така мисля, че голямото извличане от всичко това е, че обичах вашето демонстрация и обичах извеждането, което ни оставихте там, само преди малко, разговаряйки с Робин за факта, че това има определено - може би не толкова много ниша - но широко пространство, към което се прилага, що се отнася до коригиране на код и SQL и бази данни. Но бях истински развълнуван, когато чух да кажете, че можете да го пуснете с черен скрипт и да намерите някои проблеми, защото знаете, че в днешния ден и възраст ние винаги работим с най-ниската цена за всичко.
Причината да купите някъде риза за 6 долара е, че някой е изградил система, достатъчно евтина, за да произвежда и доставя и логистично да доставя и продава и продава на дребно и да извършва онлайн плащания, за да получи тази риза от 6 долара. И това не се случва, ако на хората ви се плаща 400 000 долара годишно, за да напишат код по перфектен начин; това е просто цялостно развитие. И така, този момент, предполагам, че един от въпросите, които наистина бих те обичал, просто ни дай още малко представа, каква е широчината и обхватът на типа хора, които виждаш в момента, които използват тези инструменти за профилиране код и търсите проблеми с производителността? Първоначално, исторически, откъде идват те? Били ли са големите инженерни къщи? И тогава, продължавайки напред, вярно ли е, правилно ли съм, като мисля, че все повече и повече компании прилагат този инструмент или тези инструменти, за да се опитат да помогнат на кодери, които знаят, които просто правят нещата, за да свършат работата и да го изкараш през вратата? А понякога се нуждаем от карта за излизане от затвора? Прав ли съм да мисля, че в исторически план имахме по-инженерна насоченост и развитие? Това е, че ние получаваме по-малко, както Робин каза, академичен подход, и сега е самоук, или изрязване и поставяне на код, или просто да изградим нещата? И съответства ли това на хората, които взимат продукта сега?
Берт Скалцо: Да, точно. И ще ви дам един много конкретен пример, ние просто искаме да свършим работата, защото бизнесмените не искат съвършенство. Това е нещо като компютърна игра на шах: шахматната игра не търси идеалния отговор; търси отговор, който е достатъчно добър в разумен период от време, така че така програмираме. Но това, което откривам сега, е, че повечето хора вместо да казват, че искат профилер като част от тестването на техните единици - така бих го направил, защото не го виждам като загуба на време - това, което се случва е сега, когато това се прави по-късно, понякога, по време на интеграционно тестване или стрес-тестове, ако имаме късмет. Но повечето пъти това е част от ескалация, в която нещо е започнало в производството, то е работило известно време, може би дори е работило години, а сега не работи добре и сега ще го профилираме. И това изглежда е по-често срещаният сценарий сега.
Дез Бланчфийлд: Да, и мисля, че терминът „технически дълг” вероятно е един, с който сте повече от запознат; Познавам Робин и със сигурност съм. Смятам, че в наши дни, особено при гъвкавите подходи към разработването и изграждането на системи, концепцията за технически дълг е много реално нещо и ние всъщност го отчитаме в проектите. Знам, искам да кажа, имаме собствени проекти като Media Lens и други, където ежедневно се извършва кодиране и различни неща в Bloor Group. И винаги когато строим нещо, ние някак си гледаме, аз го гледам и винаги гледаме от гледна точка на това, което ще ми струва да поправя това в момента, срещу това просто мога ли да го намеря в може и да го извадим, и след това гледайте и вижте дали това нещо ще се счупи. И наследявам този технически дълг, който знам, че ще трябва да се върна по-късно и да оправя.
И искам да кажа, че съм правил това през последните седем дни: Написах няколко инструмента и скриптове, написах няколко парчета език Python и го разгърнах в задния край на Монго, правейки сигурно е хубаво, чисто и сигурно, но просто получава заявката, която ми трябва, като знам, че имам нужда от тази функция, за да работя, за да стигна до по-големия пъзел; точно там е моята истинска болка. И така вие поемате този технически дълг и мисля, че това вече не е просто случайно нещо, мисля, че това е част от ДНК на развитието в момента. Хората просто - не безпристрастно - просто приемат техническия дълг е нормален начин на издаване и те просто трябва да го понесат. Там поемате техническия дълг. И мисля, че страхотното нещо, което ни показахте в демонстрацията, беше, че можете буквално да профилирате и да гледате колко време отнема нещо. И това вероятно е едно от любимите ми неща. Искам да кажа, че всъщност съм изградил инструменти за профилиране - използвахме за изграждане на инструменти в Sed и Lex и Orc, за да пуснем нашия код и да видим къде са бримките, преди да са налични инструменти като този - и когато сте изградили код, за да отидете и прегледайте собствения си код, получавате много добри резултати да не се налага да преглеждате собствения си код. Но това не е така сега. Имайки предвид това, има ли определен пазарен сегмент, който заема това повече от всеки друг? Виждам като маса -
Берт Скалцо: О, да, имам - ще направя аналогия за вас и ще ви покажа, че непрограмистите го правят непрекъснато. Защото, ако някога преподавам клас или сесия за отстраняване на грешки и профилиране, ще попитам хората: „Добре, колко хора тук влизат в Microsoft Word и целенасочено никога не използват проверката на правописа?“ И никой не вдига ръка, защото за писането на документи всички знаем, че можем да правим английски грешки и затова всеки използва проверката на правописа. И аз казах: „Е, как така, когато пишете текст в IDE си като Visual Basic, не използвате дебъгъра? Това е същото нещо, това е като проверка на правописа. "
Дез Бланчфийлд: Да, всъщност това е чудесна аналогия. Всъщност не съм се замислял, трябва да призная, че всъщност правя нещо подобно с няколко инструмента, които използвам. Всъщност, ODF, любимият ми с Eclipse, е просто изрязване и поставяне на код там и отивам да търся неща, които просто подчертават веднага и осъзнавам, че направих печатна грешка в някакъв клас разговор. И, но сега е интересно с този инструмент, който можете да го направите в реално време, за разлика от това да се върнете и да го разгледате по-късно, което е нещо приятно да го хванете напред. Но да, това е чудесна аналогия с просто въвеждането на текст в текстов процесор, защото това е интересно събуждане, просто осъзнайте, че сте направили грешки в грешка или дори граматична грешка, нали?
Берт Скалцо: Точно така.
Дез Бланчфийлд: И така, виждате ли повече по-сериозен проблем, предполагам, искам да кажа, последния въпрос от мен, преди да се хвърля към нашите въпроси и отговори, може би за нашите участници. Ако щяхте да дадете някаква препоръка около подхода да направите това - предполагам, че това е риторично - случаят ли е, че започвате рано и го прилагате, докато се развивате, преди да се развивате? Или е случаят, че предимно строите, движите се, изграждате нещо, а след това влезте и го профилирате по-късно? Подозирам, че е случаят да влезете рано и да се уверите, че кодът ви е чист отпред. Или случаят е, че те трябва да обмислят тази част от тяхното разгръщане?
Берт Скалцо: В идеалния случай те биха го направили предварително, но тъй като всички са в света на суматохата, където просто трябва да свършат нещата, те са склонни да не го правят, докато не попаднат на проблем с представянето, който не могат да решат добавяне на повече процесори и памет към виртуална машина.
Дез Бланчфийлд: Да. И така, всъщност споменахте нещо интересно, ако мога бързо? Споменахте преди, че това може да се стартира отвсякъде и може да говори с база данни в задната част. Така че това е удобно с бимодалната концепция, за която говорим сега, за облак в помещение / извън помещение, и от външния вид на нещата, в края на деня, ако може да говори с задния край и да видите кода, всъщност не го интересува, нали?
Берт Скалцо: Точно така, да, можете да пуснете това в облака.
Дез Бланчфийлд: Отлично, защото смятам, че точно там върви новият ни смел свят. И така, Ерик. Сега ще се върна при вас и ще видя, че тук имаме няколко въпроса и искам нашите участници да останат с нас, въпреки че сме минали през часа.
Ерик Кавана: Да, има няколко хора там, просто ще направя един бърз коментар: Берт, мисля, че метафората, аналогията, която даваш на използването на проверка на правописа, е откровено блестяща. Това е достойно за блог или два, откровено казано, защото това е добър начин да нагласите контекста на това, което правите, и колко е ценно и как всъщност трябва да бъде най-добрата практика за използване на грешка редовно, нали? Обзалагам се, че получавате някои глави да кимате, когато го изхвърлите, нали?
Берт Скалцо: Абсолютно, защото това, което им казвам, е: „Защо провеждам проверка на правописа на документите си? Не искам да се притеснявам от глупави правописни грешки. ”Е, те не искат да бъдат смутени от глупави грешки в кодирането!
Ерик Кавана: Точно така. Да, именно. Е, хора, изгаряхме се за час и пет минути тук, толкова много благодаря на всички вас за вашето време и внимание. Ние архивираме всички тези уеб чатове, не се колебайте да се върнете по всяко време и да ги проверите. Най-доброто място за намиране на тези връзки вероятно е techopedia.com, така че ще добавим това към този списък тук.
И с това ще се сбогуваме, хора. За пореден път страхотна работа, Берт, благодарение на нашите приятели от IDERA. Ще говорим с вас следващия път, всъщност ще поговорим с вас следващата седмица. Пази се! Чао чао.
