Співробітники компанії «Техопедія», 15 березня 2017 року
Винос: Ведучий Ерік Кавана обговорив налагодження та профайлювання баз даних з докторами Робіном Блором, Дезом Бланчфілдом та Бертом Скальцо IDERA.
На даний момент ви не ввійшли в систему. Будь ласка, увійдіть або зареєструйтесь, щоб переглянути відео.
Ерік Кавана: Добре, панове, це середа о 4:00 за східним часом, і це, звичайно, означає.
Робін Блор: Не чую тебе, Еріку.
Ерік Кавана: Я був там дні тому, тож ти не один. Але тому тема сьогодні - це справді цікаві речі. Ви хочете переконатися, що це відбувається у фоновому режимі у вашій компанії, якщо ви не людина, яка робить це, і в цьому випадку ви хочете переконатися, що ви робите це правильно. Тому що ми говоримо про налагодження. Ніхто не любить помилок, нікому не подобається, коли програмне забезпечення перестає працювати - люди засмучуються, користувачі стають недоброзичливими. Це не добре. Отже, ми будемо говорити про "Швидке реагування: налагодження бази даних та профілактика до порятунку".
Є місце про твою справді, зачепи мене на Twitter, @eric_kavanagh звичайно.
Цей рік - гарячий. І налагодження буде гарячим, незважаючи ні на що. Це дійсно буде однією з цих проблем, яка ніколи не піде з життя, незалежно від того, наскільки добре ми отримаємо цю справу, завжди будуть проблеми, тому ключовим є те, як дістатися до місця, де можна швидко вирішити ці проблеми? В ідеалі у вас є чудові програмісти, чудові умови, де не так вже й піде не так, але як свідчить стара приказка: «Аварії трапляються в кращих сім'ях». І те саме стосується організацій. Отже, ця штука трапляється, це станеться, питання полягає у тому, що буде вашим рішенням для вирішення цього питання та вирішення цих проблем?
Ми почуємо від доктора Робіна Блура, потім нашого власного Дез Бланчфілда знизу, і, звичайно, нашого доброго друга, Берта Скальцо, з IDERA. А насправді я віддам ключі від Робіна Блора, відберу його. Підлога ваша.
Робін Блор: Гаразд. Це цікава тема. Я думав, оскільки Дез, ймовірно, збирається продовжувати фактичні прийоми та історії війни про налагодження, я думав, що я просто пройду фонову дискусію, щоб ми мали отримати цілком округлу картину того, що відбувається. Я робив це давно, і раніше я був кодером, так це схоже, і я майже спокусився цією презентацією почати воскову ліричну ідею з відкритим кодом, але думав, що залишу це комусь іншому.
Ось список відомих помилок, і більшість із них потрапляють у головні списки будь-кого, в основному всі, крім двох останніх, коштують не менше 100 мільйонів доларів. Перший - кліматичний орбітальник Марса, загубився в космосі, і це було через проблему кодування, де люди плутали метричні одиниці із (сміється) ногами та дюймами. У Ariane Five Flight 501 сталася невідповідність між двигуном, який був увімкненим, та комп'ютерами, які повинні були запускати ракету при запуску. Кілька помилок на комп'ютері, вибух ракети, новини заголовка. Радянський газопровід 1982 року, вважається найбільшим вибухом в історії планети; Я не впевнений, чи це так. Росіяни викрали якесь автоматизоване програмне забезпечення для управління, і ЦРУ зрозуміло, що вони це робитимуть, і вкладені в нього помилки, а Рада реалізувала це без тестування. Отже, підірвав трубопровід, думав, що це забавно.
Черв'як Морріс був кодуючим експериментом, який раптом став бурхливим хробаком, який обійшов усіх - він, мабуть, завдав збитків на суму 100 мільйонів доларів; це оцінка звичайно. Intel зробила відому помилку з математичним чіпом - інструкцією з математики на мікросхемі Pentium в 1993 році - яка повинна була коштувати понад 100 мільйонів доларів. Програма «Карти Apple» - це, можливо, найгірший і найжахливіший запуск усього, що Apple коли-небудь робила. Люди, які намагалися ним скористатися, мали на увазі, що хтось їхав по 101, і виявили, що в Apple Map було сказано, що вони посеред бухти Сан-Франциско. Тож люди почали називати додаток Apple Maps як iLost. - наш найдовший відключення в 1990 році - це цікаво з точки зору вартості чогось подібного - AT&T працювали близько дев'яти годин і коштувало близько 60 мільйонів доларів на міжміські дзвінки.
І я був у страховій компанії Великобританії, і в базі даних вони впровадили нову версію бази даних, і вона почала протирати дані. І я пам’ятаю це надзвичайно добре, тому що мене потім покликали взяти участь у якомусь виділенні бази даних через це. І було дуже цікаво, що вони взяли нову версію бази даних, і у них було безліч тестів, які вони робили для нових версій бази даних, щоб вона пройшла всі тести. Він знайшов дійсно незрозумілий спосіб стерти дані.
Отже, все одно, це все. Я думав, що поговорю про невідповідність імпедансу та виданий SQL. Цікаво, що реляційні бази даних зберігають дані в таблицях і кодерах, як правило, маніпулюють даними в об'єктних структурах, які насправді не дуже добре відображають таблиці. І через це ви отримуєте те, що називається невідповідністю імпедансу, і комусь доводиться боротися з цим так чи інакше. Але що насправді відбувається, тому що одна модель, модель кодера та база даних інша модель, не особливо вирівняні. Ви отримуєте помилки, яких просто не було б, якби галузь побудувала речі, які працюють разом, що, на мою думку, є смішним. Отже, в основному, з боку кодерів, коли ви отримуєте ієрархії, це можуть бути типи, це може призвести до наборів, це може бути поганою здатністю API, це може бути багато речей, які просто викидають речі з точки зору взаємодії з базою даних. Але річ, яка для мене найбільше, справді цікава; завжди мене дивувало, що у вас був цей SQL-бар'єр, який також є своєрідним імпедансом у спосіб, коли кодери та база даних працюють один з одним. Отже, SQL має розпізнавання даних, що є прекрасним, і він має DML для вибору, проекту та об’єднання, що добре. Ви можете кинути багато можливостей з точки зору отримання даних із бази даних за допомогою цього. Але у нього дуже мало математичної мови для виконання справ. У ньому є трохи цього і того, і у нього дуже мало часу, що базується на матеріалах. І через це SQL є недосконалим, якщо вам подобається, засобом отримання даних. Таким чином, хлопці з бази даних створили збережені процедури, щоб жити в базі даних, і причина збережених там процедур полягала в тому, що ви не дуже хотіли перекидати дані туди і назад в програму.
Деякі з функціональних можливостей були надзвичайно специфічними для даних, тому це була не просто референтна цілісність та каскадні делети та подібні речі, база даних дбала про раптом ви ставите функціонал у базу даних, що, звичайно, означало, що функціональність програми може бути розділена між кодером і самою базою даних. І це зробило роботу з реалізацією деяких видів функцій справді досить складною і, отже, схильною до помилок. Отже, це одна сторона гри в базу даних, тому що це означає, що ви отримали багато реалізацій, наприклад, що я брав участь у реляційних базах даних, дійсно є дуже багато коду, який знаходиться в збережених процедурах, якими обробляється окремо від коду, який знаходиться в додатках. І здається, що це має бути дуже дивним, адже він повинен бути досить розумним робити різні речі.
Я думав, що я також поговорю про продуктивність бази даних, тому що помилки в роботі часто розглядаються як помилки, але в основному у вас може бути вузьке місце в процесорі, в пам'яті, на диску, в мережі, і у вас можуть виникнути проблеми з продуктивністю через блокування . Ідея полягала б у тому, що кодер насправді не повинен турбуватися про продуктивність, а база даних насправді працює досить добре. Він повинен бути розроблений так, що кодер не повинен знати. Однак у вас поганий дизайн бази даних, у вас поганий дизайн програми, ви отримуєте паралельність у змішуванні робочого навантаження, що також може призвести до проблем з продуктивністю. Ви отримуєте балансування навантаження, отримуєте планування потужностей, зростання даних - це може призвести до того, що база даних просто зупиниться або сповільниться. Цікава річ, коли бази даних майже заповнені, вони сповільнюються. І ви можете мати проблеми з шарами даних з точки зору реплікації та необхідності копіювання та необхідності робити резервне копіювання та відновлення. У всякому разі, це загальний огляд.
Єдине, що я хотів би сказати, - це те, що налагодження бази даних може бути настільки обтяжливим і нетривіальним - і я це кажу, тому що я багато чого зробив - і ви часто виявите, що це як усі ситуації налагодження, які я коли-небудь пережитого, це перше, що ти коли-небудь бачиш - це безлад. І вам доведеться спробувати перейти від безладу до того, щоб розібратися, як вийшов безлад. І часто, коли ви дивитесь на проблему з базою даних, все, на що ви дивитесь, - це пошкоджені дані, і ви думаєте: "Як, до біса, це сталося?"
У будь-якому разі я передам Дезу, який, мабуть, скаже більше слів мудрості, ніж я вийшов. Я не знаю, як передати тобі м'яч, Дез.
Ерік Кавана: Я пройду його, стояти поруч, триматись.
Автоматизований голос: лінії учасника вимкнено.
Ерік Кавана: Гаразд, зачекай одну секунду, дозволь мені подати Дезу м'яч.
Дез Бланшфілд: Дякую, Ерік. Так, доктор Робін Блур, ви справді найправильніші: це тема, все життя баг, якщо ви помилуєте каламбур, вибачте, що я не міг собі в цьому допомогти. Сподіваємось, ви там побачите мій перший екран, вибачте за проблему розміру шрифту вгорі. Тема помилок - це щоденна лекція, в багатьох випадках, з мого досвіду. Це така широка і широка тема, тому я збираюся зосередити увагу на двох ключових областях, зокрема на концепції того, що ми вважаємо великою помилкою, але проблемі програмування. Я думаю, що сьогодні впровадження помилки як такої зазвичай отримує інтегровані середовища розвитку, хоча вони можуть бути давно запущеними помилками. Але часто це більше так, як випадок профілювання коду, і можна записати код, який функціонує, це має бути помилка. Отже, мій слайд заголовка тут, у мене насправді була копія цього в дуже високій роздільній здатності A3, але, на жаль, він був зруйнований у ході будинку. Але це рукописна записка на аркуші програмування приблизно з 1945 року, де нібито деякі люди з Гарвардського університету в США, їх друга конструкція машини, що називається Марком II. Вони налагоджували якусь проблему загальною мовою, але вони намагалися знайти помилку, і виявляється, щось дещо відрізняється від того, що було обладнанням та нібито проблемою програмного забезпечення.
Отже, міський міф полягає в тому, що близько 9 вересня 1945 р. Команда Гарвардського університету розтягувала машину, вони натрапляли на щось, що вони називали "естафета сімдесяти" - в ті дні програмування проводилося у фізичному сенсі, ви намотували код навколо дошки, і саме так ви ефективно запрограмували машину - і вони виявили, що в цьому реле номер сімдесят щось було з цим не так, і виявляється, що власне термін «помилка» виник, тому що він буквально був моллю - нібито там була моль, вклинена між собою частиною мідного дроту, що йшов з одного місця в інше. І йдеться про те, що легендарна Грейс Хоппер, як цей підпис, для мого слайду заголовка "Перший фактичний випадок виявлення помилки" цитує цитата.
Але як Робін підкреслював раніше у своєму першому слайді, поняття про помилку йде так далеко, як ми можемо уявити, як люди роблять обчислення, поняття як накладні. Термін "патч" походить від фактичного шматка стрічки, який проклеюється над отвором на перфокарті. Але вся справа в тому, що термін "налагодження" вийшов із цієї концепції пошуку помилки у фізичній машині. І з тих пір ми використовували цю термінологію для того, щоб намагатися вирішувати проблеми, або не стільки, скільки проблеми кодування в програмі, яка не компілюється, а як програма, яка не працює добре. А конкретно, не було профільовано, просто знайдіть такі речі, як нескінченні петлі, які просто нікуди не йдуть.
Але у нас також є сценарій, і я подумав, що я поставив би кілька кумедних слайдів, перш ніж потрапити на трохи детальніше. Ось класичний мультфільм, який називається XKCD в Інтернеті, і мультиплікатор має досить кумедні погляди на світ. А це про дитину, яку називають «Столиками маленького Бобі», і нібито його батьки назвали цього маленького хлопчика Робертом); СКЛАД СТІЛЬКИ Учні; - і це називається, і начебто "Привіт, це школа твого сина, яка має деякі проблеми з комп'ютером", і батько відповідає: "О, дорогий, чи щось він зламав?" І вчитель каже: "Ну, певним чином ", і запитує вчитель, " ти справді назвав свого сина Робертом "); СКУПИТИ СТОЛИ Студенти; -? ”А батько каже:“ О так, маленький Боббі Столи, ми його називаємо ”. Як би там не було, вони продовжують говорити, що зараз втратили студентські записи, я сподіваюся, що ви щасливі. І відповідь: "Ну, ви повинні очистити та очистити свої дані в базі даних". І я використовую це багато разів, щоб говорити про деякі проблеми, які ми маємо в пошуку речей у коді, що часто код не дивиться на дані так само.
Ще один кумедний, я не знаю, справжній це чи ні - я підозрюю, що це підробка - але знову ж таки, це торкається і моєї смішної кістки. Хтось міняє номерний знак на передній частині свого автомобіля, на аналогічне твердження, що спричиняє падіння баз даних у камери швидкості тощо, що фіксує номерні знаки автомобілів. І я завжди посилаюсь на це так, що сумніваюся, що будь-який програміст передбачив потрапляння свого коду фактичним автотранспортом, але ніколи цього не варто недооцінювати - сила розлюченого вун.
(Сміх)
Але, мабуть, це призводить до мого ключового моменту, і, мабуть, це те, що колись ми могли налагоджувати та кодувати профіль як просто смертні. Але я дуже переконаний, що цей час минув, і анекдотично, на моєму досвіді, моє перше - і це мене вічно страшить, я впевнений; Робін, ти можеш розсмішити мені це заради цього - але історично я прийшов з фонового віку у віці 14 років, блукаючи кінцем міста, і постукав у двері дата-центру, який називається “Data Com” у Новій Зеландія і запитує, чи можу я заробляти кишенькові гроші в школі, повертаючи пізній автобус додому, близько 25 км маршруту щодня, ставлячи папір у принтери та стрічки в магнітофони та просто будучи генеральним адміністратором. І що цікаво, вони мені дали роботу. Але з часом мені вдалося ввійти в штатний розпис і знайти програмістів, і зрозумів, що люблю кодування, і пройшов процес запуску скриптів та пакетних завдань, який в кінці дня все ще є кодом. Ви повинні писати сценарії та пакетні завдання, схожі на міні-програми, а потім пройти весь процес сидіння в коді 3270 запису терміналу вручну.
Насправді, найпершим моїм досвідом був термінал телетайпу, який фактично був 132-колонним фізичним принтером. По суті, подумайте, як про дуже стару машинку з папером, який прокручується по ній, тому що у них не було трубки CRT. І налагодження коду на цьому було дуже нетривіальною проблемою, тому ви, як правило, писали весь код вручну, а потім діяли як машиністка, роблячи все можливе, щоб не помилитися, щоб прокрастись, бо це надзвичайно страшно. один редактор рядків перейде до певного рядка, а потім надрукує рядок, а потім знову введіть його. Але колись саме так ми писали код, і ось так ми налагоджували, і ми отримували дуже, дуже добре в цьому. І насправді це змусило нас мати дуже хороші методи програмування, адже це було справжнім клопотом виправити це. Але тоді подорож пройшла - і ми всі з цим знайомі - вона пройшла від терміналу 3270 в моєму світі, до цифрового обладнання VT220, де ви могли бачити речі на екрані, але знову ж таки, ви робили те саме ви робили на паперовій стрічці вид надрукованого формату просто на CRT, але ви змогли видалити простіше, і у вас не було такого звуку "dit dit dit dit".
І тоді ви знаєте, термінали Wyse - як, наприклад, Wyse 150 - це, напевно, мій улюблений інтерфейс до комп’ютера коли-небудь - і тоді ПК, а потім Mac, а сьогодні ці сучасні графічні інтерфейси та ідентифікатори, які базуються на веб-сторінках. І цілий спектр програм, програмування в одному і асемблері, а також PILOT, Logo та Lisp, Fortran і Pascal та мови, які можуть змусити людей скупитися. Але це мови, які змусили вас написати хороший код; вони не дозволили вам піти від поганих практик. C, C ++, Java, Ruby, Python - і ми просуваємося далі на етапі програмування, ми отримуємо більше схожих на сценарій, ми наближаємось до ближче до структуризованої мови запитів та мов, таких як PHP, які фактично використовуються для виклику SQL. Сенс сказати тобі, що, походячи з мого походження, я багато в чому був самоучкою, і ті, що допомогли мені навчитися, навчили мене дуже хорошим практикам програмування та дуже хорошим практикам дизайну та процесів, щоб переконатися, що я цього не зробив ввести код баггі.
Методи програмування в наші дні такі речі, як, наприклад, Структурована мова запитів, SQL, це дуже потужна, проста мова запитів. Але ми перетворили його на мову програмування, і я не дуже вірю, що SQL коли-небудь розроблявся як сучасна мова програмування, але ми перекосили її, щоб стати такою. І це вводить цілу купу питань, тому що ми думаємо про це з двох точок зору: з точки зору кодування та з точки зору DBA. Дуже легко придумати і ввести помилки для таких речей, як просто погані методи програмування, ледачі зусилля при написанні коду, відсутність досвіду, класичний вихованець у мене, наприклад, з SQL-людьми, що стрибають по Google і шукають щось і знаходять веб-сайт, отримав приклад і зробив копію та вставлення існуючого коду. А потім тиражувати погане кодування, недосконалість та вводити його у виробництво, адже це просто відбувається, щоб дати їм бажані результати. У вас є інші виклики, наприклад, в наші дні ми всі поспішаємо до цього, що ми називаємо гонку до нуля: намагаємось зробити все так дешево і так швидко, що у нас є сценарій, коли ми не використовуємо нижчих -оплачений персонал. І я не маю на увазі це недобросовісно, але ми не наймаємо експертів для кожної можливої роботи. Колись щось, що стосується комп'ютерів, було ракетною наукою; вона брала участь у речах, які чухалися і були дуже голосними, або виходили в космос, або інженери були висококваліфікованими чоловіками та жінками, які здобули ступінь і мали сувору освіту, яка не давала їм робити божевільні речі.
У наші дні в розробку, розробку та розробку баз даних потрапляє багато людей, які не мали багаторічного досвіду роботи, не мали обов'язкової підготовки та підтримки. І так ви закінчуєте сценарій просто традиційного аматора проти експерта. І є відомий рядок, я не можу насправді пригадати, хто створив цитату, і йдеться: "Якщо ви думаєте, що дорого наймати експерта для роботи, зачекайте, поки ви наймете пару любителів, які створюють проблему, і ви доведеться його прибирати ». І тому SQL має цю проблему, і це дуже, дуже просто вивчити, він дуже простий у використанні. Але це, на мій погляд, не ідеальна мова програмування. Дуже легко робити такі речі, як зробити вибрану зірку звідки завгодно, і перетягнути все це на мову програмування, якою вам зручніше, як PHP та Ruby чи Python, і використовувати мову програмування, з якою ви добре знайомі. маніпулювання даними, а не виконання складнішого запиту в SQL. І ми бачимо це багато, і тоді люди задаються питанням, чому база даних працює повільно; це тому, що мільйон людей намагаються придбати квиток у онлайн-системі квитків, де це вибрана зірка куди завгодно.
Зараз це справді екстремальний приклад, але ви розумієте це з усього цього. Отож, щоб просто побити цей пункт додому, ось приклад, який я багато переношу. Я великий фанат математики, люблю теорію хаосу, люблю набори Мандельброта. Праворуч є видання набору Мандельброта, з яким я впевнений, що ми всі знайомі. А ліворуч є фрагмент SQL, який насправді робить це. Тепер, кожного разу, коли я десь кладу це на екран, я чую це "О боже мій, хтось видавав серію Мандельброта з SQL, ти серйозно? Це божевільно! ”Ну, вся суть у тому, щоб проілюструвати те, що я тільки що там виклав, і це так, адже ви тепер можете програмувати майже що завгодно в SQL; це дуже розвинена, потужна, сучасна мова програмування. Якщо спочатку це була мова запитів, вона була розроблена так, щоб просто отримати дані. Отже, тепер у нас є дуже складні конструкції, і ми зберігаємо процедури, ми застосували методологію програмування до мови, і це дуже легко для поганої практики програмування, відсутності досвіду, вирізати і вставити код, низькооплачуваний персонал, який намагається бути високооплачуваним персоналом, люди роблять вигляд, що знають, але їм доводиться вчитися на роботі.
Цілий ряд речей, де кодування профілю та те, що ми називаємо налагодженням, це не стільки пошук помилок, які зупиняють роботу програм, але помилки, які просто шкодять системі та погано структурований код. Коли ви дивитесь на цей екран зараз, і думаєте, що це просто, це щось мило, і ви думаєте: "Ух, яка чудова графіка, я б хотів це запустити". Але уявіть, що ви працюєте на якійсь діловій логіці . Це виглядає досить акуратно, але говорить математично графічно викладеною теорією хаосу, але коли ви думаєте про те, для чого це потенційно може бути використане в певній бізнес-логіці, ви отримуєте картину дуже швидко. І щоб насправді проілюструвати це - і мені дуже шкода, що кольори зворотні, це повинен бути чорний фон і зелений текст, щоб бути зеленим екраном, але ви все ще можете це прочитати.
Я пішов і переглянув приклад того, що ти потенційно можеш зробити, якщо ти справді божевільний і не мав жодного досвіду, і прийшов з іншого фону програмування і застосував подобається C ++ до SQL, щоб дійсно проілюструвати мою думку, перш ніж Я передаю нашого вченого гостя з ІДЕРИ. Це структурований запит, написаний як C ++, але він закодований у SQL. І це насправді виконується, але виконується протягом приблизно трьох-п'ятихвилинного періоду. І він нібито відтягує назад один рядок даних із безлічі баз даних, декількох з'єднань.
Знову ж таки, вся справа в тому, що якщо у вас немає правильних інструментів, якщо у вас немає правильних платформ і середовищ, щоб ви могли зловити ці речі, і вони вступають у виробництво, і тоді у вас є 100 000 людей щодня потрапляючи на систему, чи годину, чи хвилину, дуже скоро ви стикаєтесь із чорнобильським досвідом, коли велике залізо починає плавитися і закопуватися до ядра планети, тому що цей фрагмент коду ніколи не повинен потрапляти у виробництво. Вибачте, ваші системи та ваші інструменти повинні це підібрати до того, як він пройде де-небудь поблизу - навіть через тестовий процес, навіть через UAT та інтеграцію систем, цей фрагмент коду має бути підібраний та виділений, а когось відвести в сторону та кажучи: "Подивіться, це дійсно гарний код, але давайте отримаємо DBA, щоб допомогти вам скласти структурований запит належним чином, бо, чесно кажучи, це просто неприємно". І URL-адреса там, ви можете піти і подивитися - це називається найскладніший запит SQL, який ви коли-небудь писали. Тому що повірте мені, що насправді компілюється, він і працює. І якщо ви вирізаєте це і вставте та просто знущаєтесь із бази даних, це буде щось, що слід спостерігати; якщо у вас є інструменти для перегляду бази даних, просто спробуйте переплавити протягом трьох - п'яти хвилин, щоб передзвонити, що є одним рядком тексту.
Отже, підсумовуючи це, маючи на увазі, весь мій досвід кодування навчив мене, що ви можете дати людям пістолет, і якщо вони не обережні, вони будуть стріляти собі в ногу; хитрість полягає в тому, щоб показати їм, де знаходиться механізм безпеки. З правильними інструментами та правильним програмним забезпеченням у вас під рукою, після того як ви зробите кодування, ви зможете переглянути свій код, ви зможете знайти проблеми шляхом профілювання коду, ви зможете знайти ефективні ненавмисні помилки, які є проблемами продуктивності, і, як я вже сказав раніше, колись, ви могли це зробити, дивлячись на зелений екран. Ти вже не можеш; є сотні тисяч рядків коду, розгорнуто десятки тисяч додатків, у деяких випадках є мільйони баз даних, і навіть суперлюдини вже не можуть це зробити вручну. Вам досить буквально потрібне правильне програмне забезпечення та потрібні інструменти у вас під рукою, і вам потрібна команда, яка використовує ці інструменти, щоб ви могли знайти ці проблеми та вирішити їх дуже швидко, перш ніж дійти до справи, тоді як Dr. Робін Блор підкреслив, що речі або стають згубними, і речі вибухають, або, звичайно, вони просто починають коштувати вам багато доларів і багато часу і зусиль, а також руйнують мораль і інше, коли вони не можуть розібратися, чому все береться довго бігати.
І маючи це на увазі, я збираюся передати нашому гостю і з нетерпінням чекаю почути, як вони вирішили це питання. І особливо демо, я думаю, що ми збираємося отримати. Еріку, я повернуся назад.
Ерік Кавана: Добре, Берт, забирай це.
Берт Скальцо: Добре, дякую. Берт Скальцо, тут від 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, у якого є налагоджувач, і ви можете побачити ліворуч, у мене зберігається процедура під назвою "перевірка на дублікати". В основному, це просто піти і подивитися, чи є у мене кілька рядків у таблиці з однаковою назвою фільму. Отже, база даних для фільмів. І ви можете побачити праворуч, у верхній третині, я отримав вихідний код посередині, я отримав те, що називається моїми змінними годинника, і моїми стеками викликів, а потім внизу я ' Ви отримали кілька вихідних повідомлень. І що тут важливо, якщо переглядати цю першу червону стрілку, якщо я клацну мишкою на змінну, я фактично можу побачити, яке значення знаходиться в цій змінній на той момент, коли я переглядаю код. І це дійсно корисно, і тоді я можу переходити по одному рядку за раз через код, мені не потрібно сказати виконувати, я можу сказати, крок рядка, дозвольте мені подивитися, що сталося, перейдіть до іншого рядка, дозвольте мені побачити, що сталося, і я роблю це в базі даних. І хоча я сиджу на Rapid SQL на своєму ПК, і моя база даних знаходиться в хмарі, я все одно можу зробити цю віддалену налагодження і побачити її та контролювати її звідси, і робити налагодження так само, як і з будь-якою іншою мовою.
Тепер наступна стрілка там - ви можете бачити маленьку стрілку, яка вказує праворуч, до цього виводу СУБД, саме там знаходиться мій курсор в даний момент, - іншими словами, я ступив, і ось де я перебуваю в момент. Отже, якщо я скажу: "Крок знову", я перейду до наступного рядка. Тепер трохи нижче ви побачите червону крапку. Ну, це точка розриву, яка говорить "Ей, я не хочу переступати ці лінії". Якщо я просто хочу перескочити все і дістатися до тієї червоної точки, я можу натиснути кнопку запуску, і вона запуститься звідси або до кінця, або до точки розриву, якщо є якісь точки прориву, і тоді вона зупиниться і дозволить мені зробити крок знову. І причина, що це все важливо, і потужна в тому, що коли я все це роблю, те, що відбувається в середині і навіть внизу, але головне в середині, зміниться, і я можу побачити значення з моїх змінних, Я можу побачити свій слід стека викликів, і тому вся ця інформація відображається там, коли я перебираю код, так що я насправді бачу і відчуваю, і розумію, що відбувається і як насправді є код працює на час виконання. І зазвичай я можу знайти проблему, якщо вона є, або якщо я досить хороший, щоб її усунути.
Гаразд, зараз я поговорю про профілера, і в цьому випадку це профайлер, який я бачу через налагоджувач. Пам'ятаєш, я казав, що вони часом окремі, а іноді можуть бути разом? У цьому випадку я знову перебуваю у Rapid SQL, і я бачу поле зліва, поруч із номерами рядків. І що це таке, це стільки секунд або мікросекунд, що знадобилося для виконання кожного рядка коду, і я це ясно бачу, весь свій час проводять у цьому циклі FOR, де я вибираю все з таблиці . І, отже, те, що відбувається всередині цього циклу FOR, певно, є те, що мені потрібно подивитися, і якщо я можу зробити це краще, він виплатить дивіденди. Я не збираюся вдосконалюватись, працюючи над тими лініями, які мають 0, 90 або 0, 86; там витрачено не так багато часу. Тепер, у цьому випадку, і знову я перебуваю в Rapid SQL, ви бачите, як я можу робити профілювання, змішане з моєю налагодженням. Тепер, що приємно, що швидкий SQL також дозволяє зробити це іншим способом. Швидкий 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 секунд? І ми насправді виявили, що вони приєднались до декарту в одному зі своїх обраних заяв, і не знали цього.
Робін Блор: Нічого собі.
Берт Скальцо: Але хтось сказав мені один раз: "Ну як вони могли приєднатися до декарту і не знати цього?", І це буде звучати справді жахливо; іноді програміст, якому не дуже зручно працювати з SQL, зробить щось на зразок дати мені декартовий приєднання, але потім поверне мені лише перший запис, тож я знаю, що я щось отримав, і мені потрібен лише перший. І тому вони не усвідомлюють, що вони просто принесли мільярд записів або вони переглядають мільярд записів, тому що вони отримали той, що їх зацікавив.
Робін Блур: Нічого, я знаю, саме так називається - ну, саме про це йшов Дез, з точки зору людей, не настільки кваліфікованих, як можливо, вони повинні бути. Якщо ви програміст, ви повинні знати, що означає видача будь-якої команди. Я маю на увазі, справді, немає рівня виправдання для цього рівня дурості. Я також припускаю, що ви, так чи інакше, просто агностик мови, що стосується цього, оскільки все це зосереджено на базі даних. Я маю рацію в цьому? Це все одно, що б ви не використовували на стороні кодування?
Берт Скальцо: Абсолютно, ви можете це зробити у Fortran або C або C ++. Насправді, на деяких Unixes ви навіть можете це зробити для своїх мов сценаріїв; вони фактично надають ті самі інструменти. І тоді я хочу повернутись на секунду за те, що ви сказали без виправдання. Я збираюся дати програмістам одну перерву, бо мені не подобається кидати програмістів під шину. Але проблема справді в академічному середовищі, тому що, коли ти йдеш вчитися бути програмістом, тебе навчають мислити за часом. Вас не навчають задавати мислення, і саме це структурована мова запитів або SQL працює з наборами; тому ми маємо об'єднання, перехрестя та мінусовий оператор. І людині, яка ніколи не думала з точки зору наборів, дуже важко кинути, відмовитися від обробки записів та працювати з наборами.
Робін Блор: Так, я з тобою з цим. Я маю на увазі, я розумію, це питання освіти; Я думаю, що це повністю питання освіти, я думаю, що програмістам природно мислити процедурно. І SQL не є процедурним, а декларативним. Ви насправді просто говорите: "Це те, що я хочу, і мені байдуже, як ви це робите", ви знаєте? Тоді як з мовами програмування ви часто закручуєте рукави, і ви перебуваєте в деталях, навіть керуючи підрахунками, роблячи цикл. Я передам:
Берт Скальцо: Ні. Добре, продовжуйте.
Так, я хотів би сказати, що ви навели ще один приклад того, що профайлер буде добре сприймати, як це продовжується з цією обробкою записів за часом. Іноді програміст, який добре працює з логікою запису, не може зрозуміти, як робити програму SQL. Ну, скажімо, він робить дві петлі FOR і в основному робить з'єднання, але він робить це на стороні клієнта. Таким чином, він робить той же ефект, що і приєднання, але він робить це сам, і профіль це сприймає, тому що ви, ймовірно, витратите більше часу, роблячи приєднання вручну, ніж дозволяючи серверу баз даних зробити це за вас.
Робін Блор: Так, це було б лихом. Я маю на увазі, ти б просто лунав навколо. Обмолот завжди поганий.
У будь-якому випадку я перейду до Деза; Я впевнений, що у нього є цікаві запитання.
Дез Бланчфілд: Дякую, так, так. Я збираюся приєднатись до вас, що не кидають програмістів під автобус. Я маю на увазі, що я провів занадто багато років у своєму житті, будучи самим кодером, на кожному рівні, ви знаєте, чи це, як ви сказали, сидячи в командному рядку машини Unix, а в деяких випадках я навіть був задіяний в декількох портах Unix від однієї апаратної платформи до іншої. І ви можете уявити виклики, які ми мали там. Але реально ось ця карта для виходу з в'язниці для кожного кодера та скриптера у світі. Це ракетна наука, досить буквально, писати по-справжньому щільно кожен раз, весь час - це ракетна наука. І відомі історії таких людей, як Денніс Річі та Брайан Кернахан, які працюють над деяким кодом незалежно, а потім переходять до чату з переглядом коду за кавою і з'ясовують, що вони написали точно той самий фрагмент коду в точно тій самій програмі, точно таким же чином. І вони зробили це в C. Але цей пуристичний рівень програмування існує дуже рідко.
Справа в тому, що щодня є лише 24 години на день, сім днів на тиждень, і ми просто повинні зробити справу. І так, якщо мова йде не лише про традиційних програмістів, DBA, і кодери, і скриптери, і sadadmin, і адміністраторів мережі, і службовців безпеки, і все, що стосується даних про громадянина в ці дні; ми чуємо, кожен просто намагається виконати свою роботу. І тому я думаю, що велике відплив від усієї цієї речі - я любив вашу демонстрацію, і я любив винос, який ви залишили нам там, лише мить назад, розмовляючи з Робіном про те, що це має особливе - можливо, не так багато ніша - але широкий простір, до якого вона застосовується, що стосується виправлення коду, SQL та баз даних. Але я був дуже радий почути те, що ти кажеш, що ти можеш творити його за допомогою сценарію оболонки і знайти деякі проблеми, адже ти знаєш, що в сьогоднішній день і вік ми завжди працюємо з найнижчою вартістю всього.
Причина, де можна придбати сорочку за 6 доларів десь, полягає в тому, що хтось побудував систему досить дешево, щоб фактично виготовляти та відправляти, а також логістично доставляти, продавати та роздрібнювати та приймати онлайн-платежі, щоб отримати сорочку 6 доларів. І цього не відбувається, якщо людям платять 400 000 доларів на рік, щоб вони писали код ідеально; це всього лише розвиток. Тож, в цьому питанні, я думаю, одне із питань, які я б дуже полюбив вас, просто дайте нам детальніше зрозуміти, у чому полягає широта та охоплення того типу людей, яких ви бачите в даний час, які застосовують такі інструменти для профілювання код і шукати проблеми з продуктивністю? Спочатку, історично, звідки вони беруться? Це були великі інженерні будинки? І тоді, рухаючись вперед, чи так це, чи правильно я вважаю, що все більше і більше компаній впроваджують цей інструмент або ці інструменти, щоб спробувати допомогти кодерам, які вони знають, які тільки роблять справи для завершення роботи. і дістати його з дверей? А іноді нам потрібна карта про вихід із в'язниці? Я маю рацію, думаючи, що історично ми мали більше інженерного спрямування та розвитку? Що зараз ми отримуємо менший, як сказав Робін, академічний підхід, і тепер це самоучка, або вирізати і вставити код, або просто набудувати речі? І чи відповідає це типу людей, які зараз приймають товар?
Берт Скальцо: Так, саме так. І я наведу вам дуже конкретний приклад, ми просто хочемо виконати роботу, тому що ділові люди не хочуть удосконалення. Це щось на зразок комп’ютеризованої гри в шахи: гра в шахи не шукає ідеальної відповіді; вона шукає відповідь, яка достатньо хороша за розумну кількість часу, тому ми так програмуємо. Але те, що я зараз знаходжу, - більшість людей замість того, щоб сказати, що вони хочуть профілера як частину свого тестування одиниці - саме так я б це зробив, бо я не бачу це як марну часу - те, що відбувається тепер, коли це робиться пізніше, іноді під час інтеграційного тестування або стрес-тестування, якщо нам пощастить. Але більшість випадків це частина ескалації, де щось вийшло у виробництво, воно тривало деякий час, можливо, навіть працювало роками, і зараз воно не працює добре, і зараз ми профайловуємо це. І, здається, зараз це більш поширений сценарій.
Дез Бланчфілд: Так, і я думаю, що термін "технічна заборгованість" - це, мабуть, один, з яким ви більше знайомі; Я знаю Робін і, безумовно, є. Я думаю, що в наші дні, особливо при спритних підходах до розробки та побудови системи, для мене концепція технічної заборгованості є справжньою справою, і ми насправді це враховуємо в проектах. Я знаю, я маю на увазі, у нас є власні проекти, такі як Media Lens та інші, де кодування відбувається щодня, і різні речі в групі Bloor Group. І кожного разу, коли ми щось будуємо, ми дивимось на це, я дивлюся на це, і завжди дивимось з точки зору того, що це буде коштувати мені зараз це виправити, порівняно з тим, чи можу я просто отримати це в можна і дістати його там, а потім дивитись і бачити, чи не зламається ця річ. І успадкуйте цю технічну заборгованість, яку я знаю, що мені доведеться піти пізніше і виправити.
І я маю на увазі, я робив це за останні сім днів: я написав пару інструментів і сценаріїв, я написав пару фрагментів мови Python, і я розгорнув її в задній край Монго, роблячи впевнений, що це приємно, чисто і безпечно, але він просто отримує запит, який мені потрібно виконати, знаючи, що мені потрібна ця функція для роботи, щоб дійти до більшої головоломки; ось де мій справжній біль. І тому ви несете цей технічний борг, і я думаю, це зараз не просто випадкова річ, я думаю, це частина ДНК, що розвивається зараз. Люди просто - не сумлінно - вони просто приймають технічну заборгованість - це нормальний спосіб випуску, і вони просто повинні її понести. Тут ви несете технічну заборгованість. І я думаю, що найкращим у тому, що ви нам показали на демонстрації, було те, що ви можете буквально профайлювати і дивитися, як довго щось потрібно запустити. І це, мабуть, одна з моїх улюблених речей. Я маю на увазі, я фактично створив інструменти для профілювання - ми використовували для створення інструментів у Sed та Lex та Orc, щоб запустити наш код і побачити, де були петлі, перш ніж такі інструменти були доступні - і коли ви створили код, щоб перейти і перегляньте свій власний код, ви дуже добре не переглядаєте власний код. Але зараз це не так. Зважаючи на це, чи існує певний сегмент ринку, який займає це більше, ніж будь-який інший? Бачить як маса -
Берт Скальцо: О так, я маю - я буду робити аналогію для вас і показувати, що непрограмісти роблять це постійно. Тому що, якщо я коли-небудь викладаю налагоджувальний і профільний клас або сесію, я запитаю людей: «Добре, скільки людей тут переходить у Microsoft Word і цілеспрямовано ніколи не використовує перевірку орфографії?» І ніхто не піднімає руку, адже для написання документів ми всі знаємо, що можемо помилитися з англійською мовою, і тому кожен використовує перевірку орфографії. І я сказав: "Ну як же, коли ви пишете текст у свій IDE, як Visual Basic, ви не використовуєте налагоджувач?" Це те саме, це як перевірка орфографії ».
Дез Бланчфілд: Так, насправді, це чудова аналогія. Я не дуже думав над цим, мушу визнати, що я справді роблю щось подібне з парою інструментів, якими користуюсь. Насправді один, ODF, мій улюблений Eclipse - це просто вирізати і вставити код там і піти шукати речі, які просто підкреслюють негайно, і зрозумівши, що я зробив помилку на друку в якомусь класовому дзвінку. Але, але зараз цікаво за допомогою такого інструменту, ви можете це робити в режимі реального часу, на відміну від повернення та перегляду його пізніше, що як би приємно впіймати його вперед. Але так, це чудова аналогія простому введенню тексту в текстовий процесор, тому що це цікавий дзвінок пробудження, просто зрозумійте, що ви зробили помилки друку чи навіть граматичну помилку, правда?
Берт Скальцо: Саме так.
Дез Бланчфілд: Отже, чи бачите ви більше сприйняття, я думаю, я маю на увазі остаточне запитання від мене, перш ніж я перейду до нашого питання, можливо, для наших відвідувачів. Якщо ви збиралися дати якусь рекомендацію щодо підходу до цього - я припускаю, що це риторично - чи це так, коли ви починаєте рано і реалізовуєте це в процесі розвитку, перш ніж розвиватись? Або це випадок, коли ви переважно займаєтесь будівництвом, рухаєтесь, щось будуєте, а потім заходьте і профіліруєте це пізніше? Я підозрюю, що це справа, щоб потрапити рано і переконатися, що ваш код чистий заздалегідь. Або випадок, що вони повинні розглянути цю частину свого післярозгортання?
Берт Скальцо: В ідеалі, вони б це зробили наперед, але оскільки всі перебувають у світі суєти, де їм просто треба зробити речі, вони, як правило, не роблять цього, поки не зіткнуться з проблемою продуктивності, яку вони не можуть вирішити додавання більше процесорів та пам'яті до віртуальної машини.
Дез Бланчфілд: Так. Отже, ви насправді згадали щось цікаве, якщо я можу швидко? Ви вже згадували, що це може бути запущено з будь-якого місця та може спілкуватися з базою даних на зворотному кінці. Тож це зручно з такою бімодальною концепцією, про яку ми говоримо зараз, про хмару, що знаходиться в приміщенні / поза приміщенням, і за виглядом речей, наприкінці дня, якщо вона може поговорити з задньою частиною і побачити код, це насправді не хвилює, чи не так?
Берт Скальцо: Так, так, ви можете запустити це в хмарі.
Дез Бланчфілд: Чудово, тому що я думаю, що саме там іде наш новий хоробрий світ. Отже, Ерік. Я зараз повернуся до вас і побачу, що у нас тут є кілька питань, і я хочу, щоб наші відвідувачі все ще залишалися з нами, хоча ми минули годину.
Ерік Кавана: Так, там є кілька людей, я просто зроблю короткий коментар: Берт, я думаю, що метафора, аналогія, яку ти даєш використанню перевірки орфографії, відверто геніальна. Це вартий блогу чи двох, відверто кажучи, адже це хороший спосіб викласти контекст того, що це ви робите, і наскільки це цінно, і як насправді має бути найкращою практикою використання налагоджувача регулярно, правда? Б'юсь об заклад, що ти кидаєш головами, коли кидаєш цю, чи не так?
Берт Скальцо: Абсолютно, тому що я їм кажу: "Чому я перевіряю орфографію своїх документів? Я не хочу, щоб мене бентежили дурні орфографічні помилки ". Ну, вони не хочуть бути збентежені дурними помилками кодування!
Ерік Кавана: Правильно. Так, справді. Ну, люди, ми прогоріли тут протягом години і п'яти хвилин, настільки велика подяка всім вам за ваш час та увагу. Ми архівуємо всі ці веб-чати, не соромтеся будь-коли повернутися і перевірити їх. Найкраще місце для пошуку цих посилань - це, мабуть, techopedia.com, тому ми додамо це до цього списку прямо тут.
І з цим ми попрощаємося, люди. Ще раз чудова робота, Берт, завдяки нашим друзям з IDERA. Ми поговоримо з вами наступного разу, ми поговоримо з вами на наступному тижні. Піклуватися! Бувай.
