Сотрудники Techopedia, 15 марта 2017 г.
Вывод: ведущий Эрик Кавана обсудил вопросы отладки и профилирования базы данных с доктором Робином Блором, Дезом Бланчфилдом и Берт Скальцо из IDERA.
Вы не вошли в систему. Пожалуйста, войдите или зарегистрируйтесь, чтобы увидеть видео.
Эрик Кавана: Хорошо, дамы и господа, в среду 4:00 по восточному времени, и, конечно, это значит.
Робин Блур: Не слышу тебя, Эрик.
Эрик Кавана: Я был там несколько дней назад, так что вы не одиноки. Но сегодня тема действительно интересная. Это то, что вы хотите убедиться, что происходит в фоновом режиме в вашей компании, если только вы не человек, который это делает, и в этом случае вы хотите убедиться, что вы делаете это правильно. Потому что мы говорим об отладке. Никто не любит ошибки, никто не любит, когда программное обеспечение перестает работать - люди расстраиваются, пользователи недружелюбны. Это не хорошо. Итак, мы поговорим о «Быстрое реагирование: отладка базы данных и профилирование на помощь».
В твоем месте действительно есть место, напиши мне в Твиттере, @eric_kavanagh, конечно.
В этом году жарко. И отладка будет горячей, несмотря ни на что. Это действительно будет одной из этих проблем, которая никогда не исчезнет, независимо от того, насколько хорошо мы справимся с этим, всегда будут проблемы, поэтому ключ в том, как добраться до места, где можно быстро решить эти проблемы? В идеале, у вас есть отличные программисты, отличные среды, в которых не так уж и много не получается, но, как гласит старая поговорка: «Аварии случаются в лучших семьях». То же самое относится и к организациям. Итак, это происходит, это должно произойти, вопрос в том, что станет вашим решением для решения этой проблемы и решения этих проблем?
Мы услышим от доктора Робина Блура, потом от нашего собственного Деза Бланчфилда изнутри, и, конечно же, от нашего хорошего друга Берта Скальцо из IDERA. И на самом деле, я собираюсь передать ключи Робину Блуру, забрать его. Вам слово.
Робин Блур: ОК. Это интересная тема. Я подумал, потому что Дез, вероятно, собирается продолжить рассказ о реальных методах и военных историях об отладке, я подумал, что просто проведу предварительную дискуссию, чтобы мы могли получить полностью округленную картину того, что происходит. Я занимался этим долгое время, и раньше я был программистом, так что это похоже на то, и я почти соблазнился этой презентацией начать лирическую речь об идее открытого исходного кода, но я думал, что оставлю это кому-то другому.
Вот список известных ошибок, и большинство из них попадают в чей-либо топ-список, по сути, все, кроме двух последних, стоят как минимум 100 миллионов долларов. Первым был орбитальный аппарат Mars Climate Orbiter, затерявшийся в космосе из-за проблемы кодирования, когда люди путали метрические единицы с (смеется) футами и дюймами. В Ariane Five Flight 501 произошло несоответствие между установленным двигателем и компьютерами, которые должны были запускать ракету при запуске. Многочисленные сбои в работе компьютеров, взрывы ракет, заголовки новостей. Советский газопровод в 1982 году, считается самым крупным взрывом в истории планеты; Я не уверен, так ли это. Русские украли какое-то программное обеспечение для автоматического управления, и ЦРУ осознало, что они собираются это сделать, и добавило в него ошибки, а Советы внедрили его без тестирования. Итак, взорвал трубопровод, подумал, что это забавно.
Червь Морриса был экспериментом по кодированию, который внезапно превратился в хищного червя, который охватил всех - он, очевидно, нанес ущерб на 100 миллионов долларов; это оценка, конечно. Intel сделала известную ошибку с математическим чипом - математическая инструкция на чипе Pentium в 1993 году - она должна была стоить более 100 миллионов долларов. Программа Apple Maps - это, возможно, худший и самый катастрофический запуск из всех, что когда-либо делал Apple. Люди, которые пытались его использовать, были, я имею в виду, кто-то ехал по 101 и обнаружил, что на карте Apple указано, что они находятся в середине залива Сан-Франциско. Итак, люди начали называть приложение Apple Maps iLost. Наш самый длительный перерыв в работе в 1990 году - это просто интересно с точки зрения стоимости чего-то подобного - AT & T отсутствовали около девяти часов и стоили около 60 миллионов долларов на междугородних звонках.
И я был в страховой компании Великобритании, и в базе данных они внедрили новую версию базы данных, и она начала стирать данные. И я это очень хорошо помню, потому что после этого меня вызвали, чтобы принять участие в выборе базы данных. И было очень интересно, что они взяли новую версию базы данных, и у них было множество тестов, которые они сделали для новых версий базы данных, которые она прошла все тесты. Он нашел действительно неясный способ стереть данные.
Так или иначе, это так. Я думал, что расскажу о несоответствии импеданса и о выданном SQL. Интересно, что реляционные базы данных хранят данные в таблицах, а кодеры имеют тенденцию манипулировать данными в структурах объектов, которые действительно не очень хорошо отображаются на таблицы. И из-за этого вы получаете то, что называется несоответствием импеданса, и кто-то должен так или иначе иметь дело с этим. Но что на самом деле происходит, потому что одна модель, модель кодера и база данных, другая модель, не особенно согласованы. Вы получаете ошибки, которых просто не было бы, если бы индустрия создала вещи, которые работают вместе, что я считаю веселым. Таким образом, в основном, на стороне кодеров, когда вы получаете иерархии, это могут быть типы, это может приводить к наборам, это может быть плохая возможность API, это может быть много вещей, которые просто выбрасывают вещи с точки зрения взаимодействия с базой данных. Но то, что для меня больше всего, действительно интересно; Меня всегда удивляло то, что у вас был этот барьер SQL, который также является своего рода импедансом в том смысле, что кодеры и база данных работают друг с другом. Итак, в SQL есть распознавание данных, и это хорошо, и в нем есть DML для выбора, проецирования и объединения, что нормально. Вы можете использовать множество возможностей для получения данных из базы данных. Но у него очень мало математического языка для ведения дел. У этого есть кое-что из этого, и у этого есть очень мало основанного на времени материала. И из-за этого SQL является несовершенным, если хотите, средством получения данных. Итак, ребята из базы данных создали хранимые процедуры для жизни в базе данных, и причина существования хранимых процедур заключалась в том, что вы на самом деле не хотели передавать данные назад и вперед в программу.
Поскольку некоторые функции были исключительно специфичны для данных, так что это была не просто ссылочная целостность и каскадное удаление, и тому подобное, база данных позаботилась обо всем, что вы добавили в базу данных, что, конечно, означало, что функциональность приложения может быть разделена между кодером и самой базой данных. И это сделало работу по реализации некоторых видов функций действительно довольно сложной и, следовательно, более подверженной ошибкам. Итак, это одна из сторон игры с базами данных, потому что это означает, что у вас есть много реализаций, например, что я принимал участие в реляционных базах данных, там действительно очень много кода, который находится в хранимых процедурах, которые обрабатываются отдельно от кода, который находится в приложениях. И кажется, что это очень странная вещь, она должна быть достаточно умной в выполнении различных вещей.
Я подумал также поговорить о производительности базы данных, потому что ошибки производительности часто рассматриваются как ошибки, но в основном вы можете столкнуться с узким местом в ЦП, в памяти, на диске, в сети, и у вас могут возникнуть проблемы с производительностью из-за блокировки, Идея будет состоять в том, что кодировщику на самом деле не нужно беспокоиться о производительности, а база данных на самом деле будет работать достаточно хорошо. Это должно быть разработано так, чтобы кодировщик не должен был знать. Однако у вас плохой дизайн базы данных, у вас плохой дизайн программы, вы получаете параллелизм в смешивании рабочей нагрузки, что также может привести к проблемам с производительностью. Вы получаете балансировку нагрузки, планирование емкости, рост данных - это может привести к остановке или замедлению работы базы данных. Интересно, что когда базы данных почти заполнены, они замедляются. И у вас могут возникнуть проблемы с уровнями данных с точки зрения репликации, необходимости репликации и необходимости выполнять резервное копирование и восстановление. Во всяком случае, это общий обзор.
Единственное, что я хотел бы сказать, это то, что отладка базы данных может быть только такой обременительной и нетривиальной - и я говорю это, потому что я сделал многое из этого - и вы часто обнаружите, что это как все ситуации в отладке, которые я когда-либо испытал, первое, что вы когда-либо увидите, это беспорядок. И вы должны попытаться перейти от беспорядка к выяснению, как возник этот беспорядок. И часто, когда вы смотрите на проблему с базой данных, все, на что вы обращаетесь - это поврежденные данные, и вы думаете: «Как, черт возьми, это произошло?»
В любом случае, я передам Дезу, который, вероятно, скажет больше слов мудрости, чем я придумал. Я не знаю, как передать тебе мяч, Дез.
Эрик Кавана: Я передам это, подожди, подожди.
Автоматический голос: приглушенные линии участников.
Эрик Кавана: Хорошо, подождите одну секунду, позвольте мне дать Дезу мяч.
Дез Бланчфилд: Спасибо, Эрик. Да, доктор Робин Блур, вы действительно правы: это тема, пожизненный багбир, если вы простите за каламбур, извините, я не смог с этим поделать. Надеюсь, вы можете увидеть мой первый экран там, мои извинения за проблему размера шрифта в верхней части. Тема ошибок - это лекция продолжительностью в один день, во многих случаях по моему опыту. Это такая широкая и широкая тема, поэтому я собираюсь сосредоточить внимание на двух ключевых областях, в частности на концепции того, что мы считаем ошибкой, а не проблемой программирования. Я думаю, что в наши дни введение ошибки, как таковой, обычно воспринимается интегрированными средами разработки, хотя они могут быть долговременными ошибками. Но часто это в большей степени относится к профилированию кода, и можно написать код, который функционирует, что должно быть ошибкой. Итак, мой титульный слайд здесь, на самом деле у меня была его копия в очень высоком разрешении A3, но, к сожалению, она была разрушена при переезде. Но это рукописная заметка на листе программирования примерно с 1945 года, где предположительно некоторые люди из Гарвардского университета в США, их вторая сборка машины под названием Mark II. Они отлаживали какую-то проблему на общем языке, но пытались найти ошибку, и оказалось, что возникло что-то немного отличающееся от того, что было аппаратным и предположительно программным.
Итак, городской миф состоит в том, что примерно 9 сентября 1945 года команда из Гарвардского университета разбирала машину, они столкнулись с тем, что они называли «реле семьдесят» - в те дни программирование было сделано в физическом смысле, вы наматывали код вокруг доски, и именно так вы эффективно запрограммировали машину - и они обнаружили, что в этом реле семидесятых было что-то не так, и оказалось, что фактический термин «ошибка» появился потому, что он был буквально молью - предположительно там был мотылек, зажатый между каким-то куском медной проволоки, идущим из одного места в другое. И история гласит, что легендарная Грейс Хоппер в качестве этого заголовка для моего титульного слайда «первый фактический случай обнаружения ошибки» цитирует цитату.
Но, как Робин подчеркивал ранее на своем первом слайде, концепция ошибки восходит к тем временам, когда мы можем представить себе, что люди делают вычисления, например, патч. Термин «патч» произошел от фактического куска ленты, наклеенного на отверстие в перфокарте. Но весь смысл этого в том, что термин «отладка» возник из этой концепции обнаружения ошибки в физической машине. И с тех пор мы использовали эту терминологию, пытаясь справиться с проблемами, либо не столько как проблемы с кодированием в программе, которая не компилируется, но как в программе, которая работает плохо. И, в частности, не был профилирован просто найти такие вещи, как бесконечные циклы, которые просто никуда не денутся.
Но у нас также есть сценарий, и я решил добавить пару забавных слайдов, прежде чем углубиться в детали. Вот классический мультфильм под названием XKCD в Интернете, и у мультипликатора есть довольно забавные взгляды на мир. А этот рассказ о ребенке по имени «Маленькие столики Бобби» и, предположительно, его родители назвали этого мальчика Роберта »; DROP TABLE Учащиеся; - и это называется, и вроде «Привет, в школе вашего сына есть какие-то проблемы с компьютером», и родитель отвечает: «О, дорогой, он что-то сломал?» И учитель говорит: «Ну, в некотором смысле, - спрашивает учитель, - ты действительно назвал своего сына Роберта?); DROP TABLE Студенты; -? »И родитель говорит:« О да, маленькие столики Бобби, которые мы ему называем ». В любом случае, они продолжают говорить, что теперь потеряли студенческие записи года, надеюсь, вы счастливы. И ответ таков: «Ну, вы должны очистить и дезинфицировать входные данные своей базы данных». И я использую это много раз, чтобы говорить о некоторых проблемах, с которыми мы сталкиваемся при поиске вещей в коде, что часто код не смотрит на данные также.
Еще один забавный, я не знаю, реально это или нет - я подозреваю, что это подделка - но опять же, это также касается моей забавной кости. Кто-то изменил номерной знак на передней части своего автомобиля, сделав аналогичное заявление, которое приводит к падению баз данных в камерах контроля скорости и т. Д., Которые фиксируют номерные знаки автомобилей. И я всегда ссылаюсь на это как на то, что сомневаюсь, что любой программист предвосхитил бы их код на реальном автомобиле, но никогда не стоит недооценивать это - мощь злого гика.
(Смех)
Но это приводит меня к моей ключевой точке, я думаю, и это то, что когда-то мы могли отлаживать и профилировать код как простые смертные. Но я очень придерживаюсь того мнения, что это время прошло, и, судя по моему опыту, это был мой первый опыт - и это будет ужасно стареть, я уверен; Робин, ты можешь высмеивать меня за это - но исторически я пришел из прошлого, когда мне было 14 лет, я бродил по окраине города и стучал в дверь дата-центра под названием «Data Com» в Нью-Йорке. Новой Зеландии и спрашиваю, смогу ли я заработать карманные деньги в школе, возвращая домой поздний автобус, примерно 25 км в день, вставляя бумагу в принтеры и ленты в ленточные накопители, и просто являясь обычным администратором. И как ни странно, они дали мне работу. Но со временем мне удалось найти себя в штате и найти программистов, и я понял, что люблю кодирование, и прошел через процесс запуска сценариев и пакетных заданий, которые в конце концов все еще остаются кодом. Вы должны написать сценарии и пакетные задания, которые выглядят как мини-программы, а затем пройти через весь процесс написания кода на терминале 3270 вручную.
Фактически, мой самый первый опыт был на терминале телетайпа, который был фактически физическим принтером с 132 колонками. По сути, представьте себе очень старую пишущую машинку с бумагой, которая пролистывала ее, потому что у них не было ЭЛТ-трубки. И отладка кода была очень нетривиальной проблемой, поэтому вы, как правило, писали весь свой код вручную, а затем вели себя как машинистка, стараясь не впустить ошибки, потому что очень печально говорить редактор одной строки, чтобы перейти к определенной строке и затем напечатать строку, а затем ввести ее обратно. Но однажды, именно так мы писали код, и именно так мы отлаживали, и у нас это получилось очень, очень хорошо. И на самом деле, это вынудило нас использовать очень хорошие методы программирования, потому что это было очень сложно исправить. Но затем путешествие прошло - и мы все знакомы с этим - оно прошло путь от терминала 3270 в моем мире до Digital Equipment VT220, где вы могли видеть вещи на экране, но опять же, вы просто делали то же самое вы делали на бумажной ленте печатный формат только на ЭЛТ, но вам было легче удалять, и у вас не было такого звука «dit dit dit dit».
И потом, вы знаете, терминалы Wyse - как Wyse 150, возможно, мой любимый интерфейс с компьютером - и затем ПК и затем Mac, а в наши дни современные GUI и идентификаторы, которые основаны на сети. И целый ряд программ: программирование на одном и на ассемблере, PILOT, Logo, Lisp, Fortran, Pascal и языки, которые могут заставить людей съежиться. Но это языки, которые заставили вас писать хороший код; они не позволили вам избежать неприятностей. C, C ++, Java, Ruby, Python - и мы продвигаемся дальше на этом этапе программирования, мы становимся все более похожими на сценарии, мы становимся все ближе и ближе к языку структурированных запросов и таким языкам, как PHP, которые фактически используются для вызова SQL. Смысл в том, чтобы сказать вам, что, исходя из своего прошлого, я был самоучкой во многих отношениях, и те, которые помогли мне учиться, научили меня очень хорошим практикам программирования и очень хорошим практикам в области дизайна и процессов, чтобы убедиться, что я этого не сделал. ввести багги код
Методы программирования в наши дни, такие как, например, язык структурированных запросов, SQL, это очень мощный и простой язык запросов. Но мы превратили его в язык программирования, и я не очень верю, что SQL когда-либо разрабатывался как современный язык программирования, но мы изменили его, чтобы стать таким. И это порождает целую кучу проблем, потому что, когда мы думаем с двух точек зрения: с точки зрения кодирования и с точки зрения администратора баз данных. Очень легко прийти и внести ошибки в такие вещи, как просто плохие методы программирования, ленивые усилия по написанию кода, недостаток опыта, классическая любимая мозоль, которую я имею, например, с людьми из SQL, которые прыгают в Google и ищут что-то и находят веб-сайт, который получил пример и делает копию и вставку существующего кода. А затем тиражирование плохого кодирования, злоупотребление служебным положением и запуск его в производство, потому что это просто дает им желаемые результаты. У вас есть другие проблемы, например, в наши дни мы все спешим к этому, что мы называем гонкой к нулю: стараемся делать все так дешево и так быстро, что у нас есть сценарий, в котором мы не используем меньше оплачиваемый персонал. И я не имею в виду это неискренне, но мы не нанимаем экспертов для каждой возможной работы. Когда-то давно что-то связанное с компьютерами было ракетостроением; он занимался вещами, которые ударялись и были очень громкими, или уходили в космос, или инженеры были высококвалифицированными мужчинами и женщинами, которые получили ученые степени и имели строгое образование, которое мешало им делать сумасшедшие вещи.
В наши дни многие люди, занимающиеся разработкой, дизайном и базой данных, не имеют многолетнего опыта, не обязательно проходят такое же обучение или поддержку. И так вы заканчиваете сценарием просто традиционного любителя против эксперта. И есть известная строка, я не могу вспомнить, кто создал цитату, строка гласит: «Если вы думаете, что нанять эксперта для выполнения работы дорого, подождите, пока вы не наймете пару любителей, которые создают проблему, и вы Я должен очистить его ». И поэтому SQL имеет эту проблему, и его очень, очень легко изучить, он очень прост в использовании. Но это, на мой взгляд, не идеальный язык программирования. Очень легко сделать такие вещи, как выбрать звезду из любой точки мира и перенести все это на язык программирования, с которым вам удобнее, например, на PHP и Ruby или Python, и использовать язык программирования, с которым вы хорошо знакомы, чтобы сделать это. манипулирование данными, а не выполнение более сложного запроса в SQL. И мы часто видим это, а потом люди задаются вопросом, почему база данных работает медленно; это потому, что миллион людей пытаются купить билет через систему онлайн-продажи билетов, где она выбирает звезду откуда угодно.
Это действительно экстремальный пример, но вы понимаете смысл всего этого. Итак, просто чтобы подчеркнуть этот момент, вот пример, который я часто беру с собой. Я большой поклонник математики, я люблю теорию хаоса, я люблю множества Мандельброта. На правой стороне есть исполнение набора Мандельброта, с которым, я уверен, мы все знакомы. А слева есть фрагмент SQL, который на самом деле это отображает. Теперь, каждый раз, когда я помещаю это где-то на экран, я слышу: «О, боже, кто-то сделал серию Мандельброта с SQL, ты серьезно? Это безумие! »Ну, весь смысл в том, чтобы проиллюстрировать то, что я только что изложил там, и это да, фактически вы теперь можете программировать практически все на SQL; это очень хорошо разработанный, мощный, современный язык программирования. Изначально это был язык запросов, он был разработан, чтобы просто получать данные. Итак, теперь у нас есть очень сложные конструкции, и у нас есть хранимые процедуры, у нас есть методология программирования, применяемая к языку, и это очень легко для плохой практики программирования, отсутствия опыта, вырезания и вставки кода, низкооплачиваемый персонал пытается быть высокооплачиваемым, люди, притворяющиеся, что они знают, но они должны учиться на работе.
Целый ряд вещей, где профилирование кода и то, что мы называем отладкой, это не столько обнаружение ошибок, которые мешают работе программ, но и ошибок, которые только вредят системе и плохо структурированному коду. Когда вы смотрите на этот экран сейчас, и вы думаете, что это просто мило, и вы думаете: «Ух, какая замечательная графика, я бы с удовольствием запустил это». Но представьте, что это работает на каком-то кусочке бизнес-логики., Это выглядит довольно аккуратно, но говорит о математической теории хаоса с графической визуализацией, но когда вы думаете о том, для чего она потенциально может быть использована в некоторой бизнес-логике, вы очень быстро получаете картину. И чтобы действительно проиллюстрировать это - и я сожалею, что цвета поменялись местами, это должен быть черный фон и зеленый текст, чтобы быть зеленым экраном, но вы все равно можете это прочитать.
Я пошел и быстро взглянул на пример того, что вы могли бы потенциально сделать, если бы вы были по-настоящему сумасшедшими и не имели никакого опыта, пришли из другого опыта программирования и применили подобные C ++ к SQL, чтобы действительно проиллюстрировать мою точку зрения, прежде чем Я передаю наш образованный гость из IDERA. Это структурированный запрос, который написан как C ++, но он написан на SQL. И он на самом деле выполняется, но выполняется в течение трех-пяти минут. И он забирает якобы одну строку данных из нескольких баз данных, из нескольких соединений.
Опять же, весь смысл в том, что если у вас нет правильных инструментов, если у вас нет правильных платформ и сред, чтобы можно было ловить эти вещи, и они попадают в производство, и тогда у вас есть 100 000 человек Попав в систему каждый день, час или минуту, очень скоро вы получите чернобыльский опыт, когда большое железо начинает плавиться и хоронить себя в ядре планеты, потому что этот кусок кода никогда не должен запускаться в производство. Прошу прощения, ваши системы и ваши инструменты должны понять это, прежде чем они приблизятся - даже в процессе тестирования, даже благодаря UAT и системной интеграции, этот фрагмент кода должен быть выбран и выделен, а кого-то следует отвести в сторону и говоря: «Послушайте, это действительно красивый код, но давайте возьмем администратора баз данных, который поможет вам правильно построить этот структурированный запрос, потому что, честно говоря, это просто отвратительно». А URL-адрес есть, вы можете посмотреть и посмотреть - он называется самый сложный SQL-запрос, который вы когда-либо писали. Потому что, поверьте мне, это на самом деле компилируется, он работает. И если вы вырезаете и вставляете это и просто копируете базу данных, на это вполне можно посмотреть; если у вас есть инструменты для наблюдения за базой данных, просто попытайтесь растаять в течение трех-пяти минут, чтобы перезвонить, что является одной строкой текста.
Итак, подводя итог, имея в виду, весь мой опыт в программировании научил меня, что вы можете дать людям оружие, и если они не будут осторожны, они будут стрелять себе в ногу; хитрость заключается в том, чтобы показать им, где находится механизм безопасности. С правильными инструментами и подходящим программным обеспечением у вас под рукой, после того, как вы выполнили кодирование, вы можете просмотреть свой код, найти проблемы, профилировав код, найти эффективные непреднамеренные ошибки, которые влияют на производительность, и, как я уже сказал, раньше, когда-то, вы могли сделать это, глядя на зеленый экран. Вы не можете больше; Есть сотни тысяч строк кода, развернуты десятки тысяч приложений, в некоторых случаях существуют миллионы баз данных, и даже супер люди не могут сделать это вручную. Вы буквально нуждаетесь в правильном программном обеспечении и правильных инструментах у вас под рукой, и вам нужна команда, чтобы использовать эти инструменты, чтобы вы могли найти эти проблемы и решить их очень, очень быстро, прежде чем вы дойдете до сути, тогда как доктор Робин Блур подчеркнул, что все или становится катастрофическим, и вещи взрываются, или, более часто, они просто начинают стоить вам много долларов и много времени и усилий и разрушают мораль и вещи, когда они не могут понять, почему вещи берутся долго бегать.
И с учетом этого я передам слово нашему гостю и с нетерпением жду возможности услышать, как они решили эту проблему. И, в частности, демо, которое я думаю получить. Эрик, я перейду обратно.
Эрик Кавана: Хорошо, Берт, убери это.
Берт Скальцо: Хорошо, спасибо. Берт Скальцо из IDERA, я менеджер по продукту для наших инструментов баз данных. И я собираюсь поговорить об отладке. Я думаю, что одна из самых важных вещей, которые Робин сказал ранее - и это очень верно, это то, что отладка является обременительной и нетривиальной, а когда вы переходите к отладке базы данных, это на порядок еще более обременительной и нетривиальной - так, чтобы была важная цитата.
OK. Я хотел начать с истории программирования, потому что часто я вижу людей, которые не отлаживают, они не используют отладчик, они просто программируют на любом языке, который они используют, и много раз мне говорят «Ну, эти вещи отладчика являются новыми, и мы еще не начали их использовать». И вот что я делаю, я показываю им эту временную диаграмму, своего рода предысторию, старость, средневековье, это вроде скажем, где мы были с точки зрения языков программирования. И у нас были очень старые языки, начиная с 1951 года с ассемблерного кода, а также с Lisp, FACT и COBOL. Затем мы попадаем в следующую группу, Pascals и Cs, а затем в следующую группу, C ++, и смотрим, где находится этот вопросительный знак - этот вопросительный знак находится примерно в промежутке между 1978 и, возможно, 1980 годом. Где-то в этом диапазоне мы имели отладчики, доступные нам, и так сказать: «Эй, я не использую отладчик, потому что это одна из тех новых вещей», тогда вы, должно быть, начали программировать, вы знаете, еще в 1950-х, потому что это Единственный способ избежать этого требования.
Еще одна забавная вещь в этом графике - Дез только что прокомментировал Грейс Хоппер, я на самом деле знал Грейс, так что это довольно забавно. А потом еще одна вещь, над которой я смеялся, это то, что он говорил о телетайпах, и я сижу там и говорю: «Чувак, это был самый большой скачок в нашей производительности, когда мы переходили от карточек к телетайпам, это был самый большой скачок за всю историю. Итак, я запрограммировал на всех языках здесь, включая SNOBOL, о котором раньше никто не слышал, это был CDC, Control Data Corporation, так что я думаю, что я становлюсь слишком стар для этой отрасли,
Дез Бланчфилд: Я собирался сказать, что вы там ужасно постарели.
Берт Скальцо: Да, я говорю вам, я чувствую себя дедушкой Симпсоном. Итак, я смотрю на отладку, и есть разные способы отладки. Вы могли бы говорить о том, что мы все считаем традиционным входом в отладчик и пошаговое выполнение кода. Но также люди будут применять свой код; вот где вы вставляете операторы в ваш код и, возможно, вы создаете выходной файл, файл трассировки или что-то в этом роде, и таким образом вы обрабатываете свой код. Я бы посчитал это отладкой, это немного сложнее, способ сделать это, но это считается. Но также у нас есть известное утверждение print: вы смотрите, и люди фактически вставляют операторы print, и я действительно видел инструмент, где - и это инструмент базы данных - где, если вы не знаете, как использовать отладчик, Вы нажимаете кнопку, и она будет вставлять операторы печати по всему вашему коду, а затем, когда вы закончите, вы нажимаете другую кнопку, и она удаляет их. Потому что так много людей отлаживают.
И причина отладки у нас двоякая: во-первых, нам нужно найти вещи, которые делают наш код неэффективным. Другими словами, обычно это означает, что есть логическая ошибка или мы пропустили бизнес-требование, но в действительности код неэффективен; это не делает то, что мы ожидали. В другой раз, когда мы идем и делаем отладку, это делается для эффективности, и это может быть логической ошибкой, но что я сделал правильно, просто он не возвращается достаточно быстро. Теперь я подчеркиваю это, потому что профилировщик, вероятно, лучше для этого второго сценария, и мы поговорим об отладчиках и профилировщиках. Кроме того, есть такая концепция удаленной отладки; это важно, потому что много раз, если вы сидите на своем персональном компьютере и используете отладчик, который обращается к базе данных, где код фактически выполняется в базе данных, вы фактически делаете то, что называется удаленной отладкой. Вы можете не осознавать этого, но это то, что происходит. И потом, у этих отладчиков очень часто есть точки останова, точки наблюдения, шаг за шагом и некоторые другие общие вещи, которые я собираюсь показать на скриншоте через мгновение.
Теперь профилирование: вы можете выполнить профилирование несколькими способами. Некоторые люди скажут, что рабочая нагрузка захватывает и воспроизводит там, где она захватывает все, что считается профилированием. Мой опыт был больше, лучше, если он сделал выборку. Нет смысла перехватывать каждое утверждение, потому что некоторые утверждения могут выполняться так быстро, что вам все равно, что вы на самом деле пытаетесь увидеть, ну, это те, которые продолжают появляться снова и снова, потому что они бегают слишком долго. Таким образом, иногда профилирование может означать выборку, а не запускать все это. И, как правило, вы получите какой-то вывод, который вы можете использовать, теперь он может быть визуальным внутри среды разработки 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, у которых есть отладчик, и вы можете видеть слева, у меня есть хранимая процедура, называемая «проверка на наличие дубликатов». По сути, он просто пойдет и посмотрит, есть ли у меня несколько строк в таблице с одинаковым названием фильма. Итак, база данных для фильмов. И вы могли видеть справа, в верхней трети, у меня есть мой исходный код посередине, у меня есть так называемые мои переменные наблюдения и мои лотки стека вызовов, а затем внизу я у меня есть несколько выходных сообщений. И что здесь важно, если вы посмотрите на эту первую красную стрелку, если я наведу указатель мыши на переменную, я на самом деле могу видеть, какое значение находится в этой переменной в данный момент времени, пока я прохожу код. И это действительно полезно, и тогда я могу шаг за шагом пройти по коду, мне не нужно говорить «выполнить», я мог бы сказать «шаг за строкой», позвольте мне посмотреть, что произошло, перейти на другую строку, позвольте мне увидеть, что произошло и я делаю это в базе данных. И хотя я сижу на Rapid SQL на своем ПК, а моя база данных находится в облаке, я все еще могу выполнять эту удаленную отладку, видеть ее и управлять ею отсюда, и выполнять отладку так же, как и на любом другом языке.
Теперь следующая стрелка там - вы можете увидеть небольшую, как стрелка, направленная вправо, к выходу этой СУБД, вот где мой курсор находится в данный момент - другими словами, я ступил и вот где я нахожусь на момент Поэтому, если я скажу: «Шаг снова», я перейду к следующей строке. Теперь чуть ниже вы увидите красную точку. Ну, это точка останова, которая говорит: «Эй, я не хочу перешагивать эти строки». Если я просто хочу перепрыгнуть через все и добраться до этой красной точки, я могу нажать кнопку запуска, и она запустится отсюда или до конца, или до точки останова, если есть какие-либо установленные точки останова, а затем он остановится и позволит мне повторить шаг. И причина, по которой это все важно и мощно, заключается в том, что когда я делаю все это, то, что происходит в середине и даже внизу - но самое главное в середине - изменится, и я могу видеть значения из моих переменных, Знаете, я вижу трассировку моего стека вызовов, и поэтому вся эта информация отображается там, когда я прохожу код, поэтому я на самом деле могу видеть, чувствовать и понимать, что происходит и как на самом деле код работает во время исполнения. И обычно я могу найти проблему, если она есть, или если я достаточно хорош, чтобы ее решить.
Хорошо, теперь я собираюсь поговорить о профилировщике, и в данном случае это профилировщик, который я вижу через отладчик. Помните, я говорил, что иногда они разлучены, а иногда они могут быть вместе? В этом случае, опять же, я использую Rapid SQL и вижу поле слева от номеров строк. И это то, что это количество секунд или микросекунд, которое потребовалось для выполнения каждой строки кода, и я ясно вижу, что все мое время тратится в этом цикле FOR, где я выбираю все из таблицы, И поэтому, что бы ни происходило внутри этого цикла FOR, мне, вероятно, нужно посмотреть, и если я смогу сделать это лучше, это принесет дивиденды. Я не собираюсь добиваться каких-либо улучшений, работая с теми линиями, которые имеют значение 0, 90 или 0, 86; там не так много времени. Теперь, в этом случае, и снова, я в Rapid SQL, вы видите, как я могу выполнить профилирование, смешанное с моей отладкой. Теперь, что приятно, Rapid SQL также позволяет вам делать это по-другому. Быстрый SQL позволяет вам сказать: «Знаете что? Я не хочу быть в отладчике, я просто хочу запустить это, а затем я хочу посмотреть графически или визуально информацию того же типа ».
И вы можете видеть, что я больше не в отладчике, и он запускает программу, и после выполнения, он дает мне графики, чтобы рассказать мне вещи, так что я вижу, что у меня есть одно утверждение, которое выглядит так, как будто оно принимает большую часть круговой диаграммы, и если я посмотрю, то на этой сетке внизу, в строке 23, снова будет цикл FOR: он занимает больше всего времени, на самом деле он темно-красный жует всю круговую диаграмму. И так, это еще один способ для профилирования. Мы называем это «Code Analyst» в нашем инструменте. Но это в основном просто профилировщик, отделенный от отладчика. Некоторым нравится делать это первым способом, другим нравится делать это вторым способом.
Почему мы делаем отладку и профилирование? Не потому, что мы хотим написать самый лучший код в мире и получить повышение заработной платы - это может быть нашей причиной, но на самом деле это не причина, по которой вы это делаете, - вы пообещали бизнесу, что сделаете что-то правильно, что ваша программа будет эффективной. Вот для чего вы будете использовать отладчик. Кроме того, бизнес конечных пользователей; они не очень терпеливы: им нужны результаты даже до того, как они нажмут клавишу. Мы должны читать их мысли и делать все мгновенно. Другими словами, это должно быть эффективно. И вот для чего мы будем использовать профилировщик. Теперь, без этих инструментов, я действительно верю, что вы этот парень в деловом костюме с луком и стрелами, и вы стреляете по цели, и у вас завязаны глаза. Потому что как вы узнаете, как программа выполняется, просто взглянув на статический код, и как вы узнаете, в какой строке она действительно потратит больше всего времени, опять же, просто взглянув на статический код? Проверка кода может включать или не включать некоторые из этих вещей, но нет гарантии, что проверка кода найдет их все. Используя отладчик и профилировщик, вы сможете найти все эти ошибки.
Хорошо, я просто собираюсь сделать очень быстрое демо здесь. Я не собираюсь продвигать продукт, я просто хочу показать вам, как выглядит отладчик, потому что люди часто говорят: «Я никогда не видел ни одного из них раньше». И это выглядит красиво на слайдах со снимками экрана., но как это выглядит, когда оно в движении? Итак, здесь, на моем экране, я запускаю наш продукт DB Artisan; у нас также есть отладчик. DB Artisan больше предназначен для администраторов баз данных, Rapid SQL - больше для разработчиков, но я видел разработчиков, которые используют DB Artisan, и я видел администраторов баз данных, которые используют Rapid. Так что не увлекайтесь продуктом. И здесь у меня есть выбор сделать отладку, но перед тем, как запустить отладку, я собираюсь извлечь этот код, чтобы вы могли увидеть, как выглядит код, прежде чем я начну его запускать. Итак, вот тот же код, который был на снимке экрана, это моя проверка на дубликаты. И я хочу отладить это, поэтому я нажимаю отладку. И теперь, это занимает мгновение, и вы говорите: «Ну, почему это занимает мгновение?» Помните удаленную отладку: отладка фактически происходит на моем сервере базы данных, а не на моем ПК. Таким образом, он должен был перейти и создать там сеанс, создать удаленную отладочную вещь, подключить мой сеанс к этому сеансу удаленной отладки и настроить канал связи.
Итак, теперь, вот моя стрелка, она вверху, строка первая, вот где я в коде. И если я нажму на третью иконку, которая является шагом, вы увидите, что стрелка только что сдвинулась, и если я продолжу нажимать ее, вы увидите, что она продолжает двигаться. Теперь, если я хочу пройти весь цикл FOR, потому что я знаю, что в этом проблема, я могу установить точку останова. Я думал, что установил это. О, блин, у меня одна из клавиш захвата экрана была сопоставлена с той же клавишей, что и отладчик, вот что вызывает путаницу. Итак, я просто вручную установил там точку останова, так что теперь вместо того, чтобы делать шаг, шаг, шаг, шаг, пока я не достигну этого, на самом деле я могу просто сказать: «Иди и запусти эту штуку», и она остановится. Обратите внимание, что он полностью переместил меня туда, где находится точка останова, так что теперь я нахожусь в контексте запуска этого цикла, я могу видеть, на что настроены все мои переменные, что неудивительно, потому что я инициализировал их все в ноль. И теперь я могу войти в этот цикл и начать смотреть на то, что происходит внутри этого цикла.
Итак, теперь он будет делать выборочный подсчет из моих прокатов, и я могу навести указатель мыши на этого парня и посмотреть, ему два, два больше, чем один, так что, вероятно, он сделает следующий фрагмент этого кода. Другими словами, он что-то нашел. Я просто собираюсь идти вперед и позволить этому бежать. Я не хочу проходить все здесь; Я хочу показать вам, что когда отладчик завершен, он завершает работу, как обычная программа. У меня установлена точка останова, поэтому, когда я сказал запустить, она просто вернулась к следующей точке останова. Я позволяю ему работать до конца, потому что я хочу, чтобы вы увидели, что отладчик не меняет поведение программы: когда она закончится, я должен получить точно такие же результаты, если бы я ее не запускал внутри отладчика.
И с этим я собираюсь приостановить демонстрацию и вернуться, потому что мы хотим убедиться, что у нас есть время для вопросов и ответов. И так, я открою это для вопросов и ответов.
Эрик Кавана: Хорошо, Робин, может, у тебя вопрос, а потом пара из Деза?
Робин Блур: Да, конечно, я нахожу это захватывающим, конечно. Я работал с такими вещами, но я никогда не работал с такими в базе данных. Можете ли вы дать мне некоторое представление о том, для чего люди используют профилировщик? Потому что, похоже, они смотрят - потому что я предполагаю, что они - они смотрят на проблемы с производительностью, поможет ли вам отличить, когда база данных занимает время и когда код требует времени?
Берт Скальцо: Вы знаете, это фантастический вопрос. Допустим, я работаю в Visual Basic, и внутри своей Visual Basic я буду называть Transact-SQL или PL / SQL. Позвольте мне сделать PL / SQL, поскольку Oracle не всегда хорошо работает с инструментами Microsoft. Я мог бы профилировать свой код Visual Basic, и профиль там может сказать: «Эй, я вызвал эту хранимую процедуру, и это заняло слишком много времени». Но затем я могу перейти к хранимой процедуре и сделать профиль базы данных на сохраненной выполните процедуру и скажите: «Хорошо, из 100 приведенных здесь утверждений, вот пять, которые вызвали проблему». Итак, вам, возможно, придется создать команду тегов, где вам придется использовать несколько профилировщиков.
Идея состоит в том, что если вам когда-нибудь сообщат, что проблема с производительностью находится в вашей базе данных, профиль базы данных может помочь вам найти иголку в стоге сена, на которой заявления действительно являются теми, где у вас есть проблема. Я расскажу вам еще одну вещь, которая возникла при профилировании: если у вас есть фрагмент кода, который вызывается миллион раз, но он занимает микросекунду каждый миллион раз, но вызывается миллион раз, то, что показал бы профилировщик Эта вещь побежала за это много единиц времени. И поэтому, хотя код может быть очень эффективным, вы можете посмотреть и сказать: «О, мы слишком часто обращаемся к этому куску кода. Возможно, нам следует называть это только так часто, а не каждый раз, когда мы обрабатываем запись »или что-то в этом роде. Таким образом, вы можете найти эффективный код, который вызывается слишком часто, и это проблема производительности.
Робин Блур: Да, это замечательно. Я никогда этого не делал. Видите ли, конечно, когда у меня были проблемы с базой данных, это было так, как если бы я так или иначе имел дело с базой данных или с кодом; Я никогда не мог иметь дело с ними обоими одновременно. Но там, опять же, я не делал - я никогда не участвовал в создании приложений, в которых у нас были хранимые процедуры, поэтому я полагаю, что я никогда не сталкивался с проблемами, которые приводили меня в бешенство, идея, что вы разделил код между базой данных и программой. Но так, делайте все - я предполагаю, что ответ будет положительным, но это часть деятельности команды разработчиков, когда вы тем или иным образом пытаетесь исправить что-то сломанное или, возможно, пытаетесь принести новый Приложение вместе. Но все ли это связано со всеми другими компонентами, которые я ожидал бы в окружающей среде? Могу ли я ожидать, что смогу связать это вместе со всеми моими тестовыми пакетами и всем остальным, что я буду делать, и со своими вещами по управлению проектами, вот как все это скрепляется?
Берт Скальцо: Да, это может стать частью любого структурированного процесса для ваших усилий по программированию или разработке. И это забавно, на прошлой неделе у меня был заказчик, который создавал веб-приложение, и его база данных была маленькой, исторически, и поэтому тот факт, что они были не очень хорошими программистами, никогда не причинял им вреда. Ну, их база данных выросла за эти годы, и теперь она занимает 20 секунд на веб-странице, между тем, когда вы говорите «Войдите в систему и дайте мне некоторые данные, чтобы увидеть», и когда на самом деле появляется экран, и теперь это проблема с производительностью. И они знали, что проблема не была ни в их Java, ни в тех других местах. Но у них было тысячи хранимых процедур, и поэтому им пришлось начать профилирование хранимых процедур, чтобы выяснить, почему эта веб-страница занимает 20 секунд? И мы действительно обнаружили, что у них было декартово объединение в одном из их избранных утверждений, и мы не знали этого.
Робин Блур: Вау.
Берт Скальцо: Но кто-то однажды сказал мне: «Ну, как они могли присоединиться к Декарту и не знать этого?» И это будет звучать действительно ужасно; иногда программист, которому не очень комфортно с SQL, делает что-то вроде «Декартового соединения», но затем возвращает мне только первую запись, так что я знаю, что у меня что-то есть, и мне нужна только первая. И поэтому они не понимают, что просто вернули миллиард записей или просмотрели миллиард записей, потому что получили тот, который им был интересен.
Робин Блур: Ух ты, я знаю, это то, что называется - ну, это то, о чем говорил Дез, с точки зрения людей, не настолько опытных, как, возможно, они должны быть, вы знаете. Если вы программист, вы должны знать, каковы последствия использования любой команды. Я имею в виду, действительно, нет никакого оправдания этому уровню глупости. Я также предполагаю, что вы, так или иначе, просто независимы от языка в этом отношении, потому что все это сосредоточено на стороне базы данных. Я прав в этом? Это то же самое, что вы используете на стороне кодирования?
Берт Скальцо: Безусловно, вы можете сделать это на Фортране или C или C ++. Фактически, в некоторых Unixes вы можете сделать это даже для их языков сценариев; на самом деле они предоставляют одни и те же инструменты. А потом я хочу вернуться на секунду назад к тому, что вы сказали, без оправдания. Я собираюсь дать программистам один перерыв, потому что я не люблю бросать программистов под шину. Но проблема действительно в академической среде, потому что, когда вы учитесь быть программистом, вас учат думать по-новому. Вас не учат мышлению множеств, и это то, что язык структурированных запросов или SQL работает с множествами; Вот почему у нас есть объединение, оператор пересечения и минус. И человеку, который никогда не задумывался о наборах, иногда очень трудно бросить, отпустить обработку записей и работать с наборами.
Робин Блур: Да, я с тобой об этом. Я имею в виду, я понимаю, это проблема образования; Я думаю, что это полностью вопрос образования, я думаю, что для программистов естественно мыслить процедурно. И SQL не процедурный, а декларативный. Вы на самом деле просто говорите: «Это то, что я хочу, и мне все равно, как вы это делаете», понимаете? Принимая во внимание, что с языками программирования вы часто закатываете рукава, и вы в мелочах даже управляете счетами, пока делаете цикл. Я передам …
Берт Скальцо: Нет. Хорошо, продолжайте.
Да, я собирался сказать, что вы привели еще один пример того, что профилировщик был бы неплохо уловить, что-то вроде обработки этой записи за один раз. Иногда программист, хорошо разбирающийся в логике записи за один раз, не может понять, как сделать программу на SQL. Хорошо, скажем, он делает два цикла FOR и в основном выполняет соединение, но он делает это на стороне клиента. Таким образом, он выполняет тот же эффект, что и объединение, но делает это сам, и профиль поймает это, потому что вам, вероятно, придется тратить больше времени на объединение вручную, чем позволить серверу баз данных сделать это за вас.
Робин Блур: Да, это будет катастрофа. Я имею в виду, вы бы просто бродили вокруг. Молотить всегда плохо.
В любом случае, я передам Дезу; Я уверен, что у него есть несколько интересных вопросов.
Дез Бланчфилд: Спасибо, да, знаю. Я собираюсь присоединиться к вам, чтобы не бросать программистов под автобус. Я имею в виду, я провел слишком много лет в своей жизни, будучи самим программистом, на каждом уровне, знаете ли, как вы сказали, сидя в командной строке Unix-машины, а в некоторых случаях я даже участвовал в паре разных портов Unix с одной аппаратной платформы на другую. И вы можете себе представить проблемы, которые у нас были там. Но реальность такова, что вот эта карта выхода из тюрьмы для каждого программиста и сценариста в мире. Это в буквальном смысле ракетостроение, в буквальном смысле, писать очень плотно каждый раз, все время, это ракетостроение. И знаменитые истории таких людей, как Деннис Ритчи и Брайан Кернахан, которые независимо друг от друга работали над каким-то фрагментом кода, а затем обратились к чату проверки кода за чашкой кофе и выяснили, что они написали точно такой же фрагмент кода в одной и той же программе, точно так же. И они сделали это на C. Но этот пуристский уровень программирования существует очень редко.
Дело в том, что на ежедневной основе есть только 24 часа в сутки, семь дней в неделю, и нам просто нужно что-то сделать. И так, когда речь идет не только о традиционных программистах, администраторах баз данных, кодировщиках и сценариях, а также сисадминах, сетевых администраторах и сотрудниках службы безопасности, а также обо всем, вплоть до данных о гражданах в эти дни; мы слышим, все просто пытаются сделать свою работу. И поэтому я думаю, что замечательный вывод из всего этого - мне понравилась ваша демонстрация, и мне понравился вынос, с которым вы оставили нас там, всего минуту назад, разговаривая с Робином о том факте, что в этом есть что-то особенное - возможно, не так сильно ниша - но широкое пространство, к которому она применяется, в том, что касается исправления кода, SQL и баз данных. Но мне было очень приятно услышать, как вы говорите, что вы можете вставить его в сценарий оболочки и найти некоторые проблемы, потому что вы знаете, что в наши дни мы всегда работаем с минимальными затратами на все.
Причина, по которой вы можете купить где-нибудь рубашку за 6 долларов, заключается в том, что кто-то создал систему достаточно дешево, чтобы фактически производить, отгружать, доставлять, продавать и продавать в розницу, а также принимать онлайн-платежи, чтобы получить эту рубашку за 6 долларов. И этого не произойдет, если у вас есть люди, которым платят 400 000 долларов в год, чтобы написать код идеальным способом; это всего лишь развитие. Итак, на данный момент, я думаю, один из вопросов, который я бы очень хотел, чтобы вы дали нам немного больше понимания, заключается в том, какова широта и охват тех людей, с которыми вы встречаетесь в настоящее время, которые используют эти виды инструментов для профилирования. код и искать проблемы с производительностью? Первоначально, исторически, откуда они берутся? Это были большие инженерные дома? И затем, продолжая, верно ли это, я прав, полагая, что все больше и больше компаний внедряют этот инструмент или эти инструменты, чтобы попытаться помочь кодировщикам, которые, как они знают, просто делают вещи, чтобы завершить работу и вытащить это за дверь? И иногда нам нужна карта выхода из тюрьмы? Правильно ли я считаю, что исторически у нас было больше инженерного внимания и развития? Что теперь у нас меньше, как сказал Робин, академического подхода, а теперь это самоучка, или вырезать и вставить код, или просто создать вещи? И соответствует ли это типу людей, которые сейчас принимают продукт?
Берт Скальцо: Да, именно. И я приведу вам очень конкретный пример, мы просто хотим сделать работу, потому что деловые люди не хотят совершенства. Это похоже на компьютерную игру в шахматы: шахматная игра не ищет идеального ответа; он ищет ответ, который достаточно хорош в разумные сроки, поэтому мы так программируем. Но сейчас я обнаружил, что большинство людей вместо того, чтобы сказать, что они хотят получить профилировщик в рамках своего модульного тестирования, - вот как я это сделаю, потому что я не считаю это пустой тратой времени. теперь, когда это делается, иногда, во время интеграционного тестирования или стресс-тестирования, если нам повезет. Но в большинстве случаев это часть эскалации, когда что-то пошло в производство, оно работало какое-то время, может быть, даже работало годами, а теперь не работает, и теперь мы будем профилировать. И это, кажется, более распространенный сценарий сейчас.
Дез Бланчфилд: Да, и я думаю, что термин «технический долг», вероятно, тот, с которым вы более чем знакомы; Я знаю Робина, и я, конечно, есть. Я думаю, что в наши дни, особенно в гибких подходах к разработке и системному построению, для меня концепция технического долга сейчас является очень реальной вещью, и мы фактически учитываем ее в проектах. Я знаю, я имею в виду, у нас есть свои собственные проекты, такие как Media Lens и другие, где у нас есть ежедневное кодирование, и различные вещи в Bloor Group. И всякий раз, когда мы что-то строим, мы как-то смотрим, я смотрю на это и всегда смотрю с точки зрения того, что будет стоить мне исправить это прямо сейчас, вместо того, чтобы просто получить это в можно и получить это там, а затем посмотреть и посмотреть, не сломается ли эта вещь. И унаследуй этот технический долг, который, как я знаю, мне придётся позже вернуть и исправить.
И я имею в виду, я сделал это за последние семь дней: я написал несколько инструментов и сценариев, я написал несколько кусков языка Python и развернул его в бэкэнде Mongo, сделав конечно, он красивый, чистый и безопасный, но он просто выполняет запрос, который мне нужен, зная, что мне нужна эта функция для работы, чтобы добраться до большой головоломки; вот где моя настоящая боль. Итак, вы несете этот технический долг, и я думаю, что это теперь не просто случайность, я думаю, что это часть ДНК развития сейчас. Люди просто - не лукаво - они просто принимают технический долг - это нормальный тип проблемы, и им просто приходится его брать на себя. Это где вы несете технический долг. И я думаю, что самое замечательное в том, что вы показали нам в демоверсии, это то, что вы можете буквально описать профиль и посмотреть, сколько времени потребуется для запуска. И это, наверное, одна из моих любимых вещей. Я имею в виду, что я на самом деле создал инструменты профилирования - мы использовали инструменты для сборки в Sed, Lex и Orc, чтобы запустить наш код и посмотреть, где были циклы, до того, как стали доступны инструменты, подобные этой, - и когда вы создали код, который нужно было просматривайте свой собственный код, вы получаете очень хорошее отсутствие необходимости проверять свой собственный код. Но сейчас это не так. Имея это в виду, существует ли определенный сегмент рынка, который занимает это больше, чем любой другой? Видя, как масса
Берт Скальцо: О да, у меня есть … Я собираюсь провести аналогию для вас и показать, что непрограммисты делают это постоянно. Потому что, если я когда-нибудь преподаю отладчик и профилирую класс или сессию, я спрошу людей: «Хорошо, сколько людей здесь заходят в Microsoft Word и целенаправленно никогда не используют программу проверки орфографии?» И никто не поднимает руку, потому что для написания документов мы все знаем, что мы можем делать ошибки на английском языке, и поэтому все используют программу проверки орфографии. И я сказал: «Хорошо, почему, когда вы пишете текст в вашей IDE, такой как Visual Basic, вы не используете отладчик? Это то же самое, это как проверка орфографии.
Дез Бланчфилд: Да, на самом деле это отличная аналогия. Я действительно не задумывался, должен признать, что на самом деле я делаю нечто подобное с парой инструментов, которые я использую. На самом деле, один из них, ODF, мой любимый в Eclipse - просто вырезать и вставлять туда код и искать вещи, которые сразу выделяются, и понимая, что я сделал опечатку в каком-то вызове класса. И, что интересно, теперь с помощью такого инструмента вы можете делать это в режиме реального времени, а не возвращаться и смотреть на него позже, что было бы неплохо, если бы он был уловим заранее. Но да, это отличная аналогия простого помещения текста в текстовый процессор, потому что это интересный пробуждающий сигнал, просто осознайте, что вы допустили опечатки или даже грамматическую ошибку, верно?
Берт Скальцо: Точно.
Дез Бланчфилд: Итак, теперь вы видите больше всплесков, я думаю, я имею в виду последний вопрос от меня, прежде чем я, возможно, передам наши вопросы и ответы для наших посетителей. Если вы собирались дать какую-то рекомендацию в отношении подхода к этому - я предполагаю, что это риторический вопрос - это тот случай, когда вы входите рано и внедряете это в процессе разработки, прежде чем приступить к разработке? Или это тот случай, когда вы в основном строите, двигаетесь, строите что-то, а затем заходите и профилируете это позже? Я подозреваю, что дело в том, чтобы войти рано и убедиться, что ваш код чист. Или это тот случай, когда они должны рассмотреть эту часть своего пост-развертывания?
Берт Скальцо: В идеале, они будут делать это заранее, но поскольку все находятся в суетном мире, где им просто нужно что-то сделать, они не будут делать это, пока не столкнутся с проблемой производительности, которую не могут решить добавление большего количества процессоров и памяти на виртуальную машину.
Дез Бланчфилд: Да. Итак, на самом деле вы упомянули что-то интересное, если я могу быстро? Вы упомянули ранее, что это может быть запущено из любого места и может общаться с базой данных на серверной части. Так что это устраивает своего рода бимодальную концепцию, о которой мы сейчас говорим, о локальном / внешнем облаке, а также о внешнем виде вещей, в конце концов, если он может поговорить с серверной частью и увидеть код, это действительно не волнует, не так ли?
Берт Скальцо: Точно, да, вы можете запустить это в облаке.
Дез Бланчфилд: Отлично, потому что я думаю, что именно в этом направлении движется наш новый храбрый мир. Итак, Эрик. Я собираюсь вернуться к вам сейчас и увидеть, что у нас есть несколько вопросов здесь, и я хочу, чтобы наши посетители все еще оставались с нами, даже если мы прошли час.
Эрик Кавана: Да, есть несколько человек, я просто сделаю небольшой комментарий: Берт, я думаю, что метафора, аналогия, которую вы даете использованию проверки правописания, откровенно блестящая. Откровенно говоря, это достойно одного или двух блогов, потому что это хороший способ сформулировать контекст того, что вы делаете, и насколько это ценно, и как это действительно должно быть наилучшей практикой при использовании отладчика. на регулярной основе, верно? Могу поспорить, что вы киваете головой, когда выбрасываете это, верно?
Берт Скальцо: Абсолютно, потому что я говорю им: «Почему я проверяю орфографию своих документов? Я не хочу смущаться из-за глупых орфографических ошибок ». Ну, они не хотят смущаться из-за глупых ошибок кодирования!
Эрик Кавана: Точно. Да, в самом деле. Ну, ребята, мы прожили здесь час и пять минут, так что большое спасибо всем вам за ваше время и внимание. Мы архивируем все эти веб-чаты, не стесняйтесь возвращаться в любое время и проверять их. Лучшее место для поиска этих ссылок, вероятно, techopedia.com, поэтому мы добавим это в этот список прямо здесь.
И с этим, мы собираемся попрощаться с вами, ребята. Еще раз, Берт, отличная работа, спасибо нашим друзьям из IDERA. Мы поговорим с вами в следующий раз, на самом деле мы поговорим с вами на следующей неделе. Береги себя! Пока-пока.
