Особље Тецхопедиа, 15. марта 2017
Изношење: Домаћин Ериц Каванагх разговарао је о уклањању погрешака и профилирању базе података са др Робин Блоор-ом, Дез Бланцхфиелд-ом и Берте Сцалзо-ом ИДЕРА-е.
Тренутно нисте пријављени. Пријавите се или пријавите да бисте видели видео.
Ериц Каванагх: У реду, даме и господо, у среду је 4:00 по источном времену, и то наравно значи.
Робин Блоор: Не чујем те, Ериц.
Ериц Каванагх: Био сам тамо пре неколико дана, тако да ниси сам. Али, тако да је данашња тема заиста занимљива ствар. То је врста ствари за које желите да будете сигурни да се дешава у позадини ваше компаније, осим ако нисте особа која то ради, у ком случају желите да будете сигурни да то радите правилно. Јер говоримо о уклањању погрешака. Нитко не воли бугове, нико не воли када софтвер престане радити - људи се узнемире, корисници постану непријатељски расположени. То није добро. Дакле, разговараћемо о „брзом одговору: Отклањање погрешака базе података и профилисање до спашавања“.
Доиста постоји спот о твом, погоди ме на Твиттеру, @ериц_каванагх, наравно.
Ова година је врућа. И уклањање погрешака биће вруће, без обзира на све. То ће заиста бити један од ових проблема који никад неће нестати, без обзира колико добро се снашли у тим стварима, увек ће бити проблема, па кључно је како доћи до места где можете брзо да решите та питања? У идеалном случају имате сјајне програмере, сјајна окружења у којима не иде превише погрешно, али као што каже стара изрека: „Несреће се догађају у најбољим породицама.“ И исто важи за организације. Дакле, ово ће се догодити, десиће се, питање је шта ће бити ваше решење за суочавање са тим и решавање тих проблема?
Чућемо се са др Робин Блоор-ом, затим нашим Дезом Бланцхфиелд-ом одоздо, и наравно, нашим добрим пријатељем, Бертом Сцалзоом, из ИДЕРА-е. А у ствари, предаћу вам кључеве Робин Блоор, однесите га. Спрат је твој.
Робин Блоор: ОК. Ово је занимљива тема. Мислио сам да ће Дез вјероватно наставити о стварним техникама и ратним причама о уклањању погрешака и помислио сам да ћу само направити расправу у позадини како бисмо добили потпуно заокружену слику онога што се догађа. То сам радио дуго, и некада сам био кодер, тако да је то тако, и скоро сам био у искушењу са овом презентацијом да започнем воштање лирике о идеји отвореног кода, али мислио сам да то оставим неком другом.
Ево листе познатих грешака, а већина њих се налази на нечијој топ листи, у основи, све осим последње две коштају најмање 100 милиона долара. Први је био Марс климатски орбитер, изгубио се у свемиру и то због проблема са кодирањем, где су људи збунили метричке јединице са (смех) ногама и инчима. У Ариане Фиве Флигхт 501 дошло је до неусклађености између мотора који је укључен и рачунара који су требали покретати ракету када је била лансирана. Вишеструки кварови на рачунару, експлозија ракете, вести о насловима. Совјетски гасовод 1982. године, за који се сматра да је највећа експлозија у историји планете; Нисам сигуран да ли је. Руси су украли неки аутоматизовани управљачки софтвер, а ЦИА је схватила да ће то урадити и убацила грешке у њега, а Совјети су то спровели без тестирања. Дакле, дигао је нафтовод, помисливши да је то забавно.
Црв Моррис био је кодни експеримент, који је одједном постао разуздан црв који је обишао све - по свему судећи нанео је штету у вредности од 100 милиона долара; то је процена, наравно. Интел је направио познату грешку са математичким чипом - инструкцијом из математике на Пентиум чипу 1993. године - која је требало да кошта више од 100 милиона долара. Аппле-ов програм Мапс је вероватно најгоре и најстрашније покретање свега што је Аппле икада урадио. Мислим, људи који су покушали да је користе, мислим да се неко возио по 101, и открили да је Аппле Мап рекао да се налазе усред залива Сан Франциско. Тако су људи почели да називају апликацију Аппле Мапс као иЛост. - наш најдужи прекид у 1990. години - то је управо занимљиво са становишта трошкова нечег таквог - АТ&Т су радили око девет сати и коштали су око 60 милиона долара у међуградским позивима.
А ја сам био у осигуравајућој компанији у Великој Британији и бази података, имплементирали су нову верзију базе података и она је почела брисање података. И тога се добро сећам, јер сам након тога позван да учествујем у некој врсти избора база података због тога. И било је веома занимљиво да су узели нову верзију базе података, а имали су и батерију тестова коју су урадили за нове верзије базе података које су прошле све тестове. Пронашао је заиста нејасан начин за брисање података.
Дакле, свеједно, то је то. Мислио сам да ћу говорити о неусклађености импеданце и изданом СКЛ-у. Занимљиво је да релацијске базе података похрањују податке у табеле и кодрере и имају тенденцију да манипулирају подацима у објектним структурама које се стварно не пресликавају у табеле. И због тога добивате оно што се назива неусклађеношћу импеданције и неко се мора суочити с тим на неки или други начин. Али шта се заправо догађа, јер један модел, модел кодира и други модел базе података нису нарочито усклађени. Добијате грешке који се једноставно не би догодили да је индустрија градила ствари које раде заједно, а мислим да је смешно. Дакле, у основи кодирача, када добијете хијерархије, то могу бити типови, могу резултирати скупови, могу бити слабе могућности АПИ-ја, може бити пуно ствари које једноставно избацују ствари у смислу интеракције са базом података. Али ствар која је за мене највише заиста занимљива; увек ме је изненадило што сте имали ову СКЛ баријеру која је такође својеврсна импеданција на начин да кодери и база података раде један са другим. Дакле, СКЛ има препознавање података, што је у реду и има ДМЛ за одабир, пројекат и придруживање, што је у реду. Можете бацити пуно могућности у погледу избацивања података из базе података с тим. Али има врло мало математичког језика за обављање ствари. Има мало тога и онога, и има врло мало времена заснованих на стварима. Због тога је СКЛ несавршен, ако желите, начин за добијање података. Дакле, дечки из базе уградили су похрањене процедуре како би живели у бази података, а разлог за похрањене процедуре које живе тамо је тај што заправо нисте желели да бацате податке назад и назад у програм.
Неке су функционалности биле изузетно специфичне за податке, тако да није био само референтни интегритет и каскадно бришући и такве ствари, база података је водила рачуна о изненадном стављању функционалности у базу података, што је наравно значило да функционалност апликације се може поделити између кодера и саме базе података. А то је учинило посао имплементације неких врста функција заиста прилично тешким и самим тим више склоним грешкама. Дакле, то је једна страна игре са базама података, јер то значи да имате на примјер пуно имплементација, да сам био укључен у релацијске базе података заиста постоји јако пуно кода који сједи у похрањеним процедурама којима се рукује одвојено од кода који се налази у апликацијама. А чини се да је то морало бити врло необично, требало би бити прилично паметно радити разне ствари.
Мислио сам да ћу такође разговарати о перформансама базе података јер се грешке у перформансама често сматрају грешкама, али у основи можете имати уско грло у ЦПУ-у, у меморији, на диску, на мрежи и можете имати проблема са перформансама због закључавања . Идеја би била да кодер заиста не треба да се брине о перформансама и да би база података у ствари била прилично добра. То би требало бити дизајнирано тако да кодер не треба знати. Међутим, добијате лош дизајн базе података, добијате лош дизајн програма, добијате истовремено сагласност у мешању радног оптерећења, што такође може довести до проблема са перформансама. Добивате балансирање оптерећења, планирате капацитет, раст података - што може довести до тога да се база података само заустави или успори. Занимљива је ствар када се базе података скоро пуне, успоравају. И можете имати проблем са слојевима података у смислу репликације и потребе за копирањем и потребом за прављење резервних копија и опоравка. У сваком случају, то је општи преглед.
Једино што бих хтео да кажем је да отклањање грешака у базама података може бити само напорно и не-тривијално - и то кажем зато што сам пуно тога урадио - и често ћете открити да је то као у свим ситуацијама у исправљању грешака које икада доживљено је, прва ствар коју сте икада видели је неред. И морате покушати и прећи из нереда да бисте сазнали како је до нереда дошло. А често када гледате издавање базе података, све што гледате су оштећени подаци и мислите: "Како се дођавола то догодило?"
У сваком случају, прећи ћу на Деза који ће вероватно рећи више речи мудрости него што сам испао. Не знам како да ти пренесем лопту, Дез.
Ериц Каванагх: Проћи ћу, спремам се, сачекај.
Аутоматизирани глас: линије учесника су искључене.
Ериц Каванагх: У реду, сачекај тренутак, дај ми Дез лопту.
Дез Бланцхфиелд: Хвала, Ериц. Да, др Робин Блоор, заиста сте најтачнији: ово је тема, доживотна глупост ако ћете се опростити с пуницом, жао ми је што нисам могао себи да помогнем. Надам се да ћете тамо моћи да видите мој први екран, извињавам се због проблема са величином фонта. Тема грешака је свакодневно предавање, у многим случајевима из мог искуства. То је тако широка и широка тема, тако да ћу се усредсредити на две кључне области, конкретно на концепт онога што ми сматрамо грешком, али проблем програмирања. Мислим да ових дана увођење грешака по себи углавном долази из интегрисаних развојних окружења, иако су можда дуготрајне грешке. Али често је то више случај код профилирања кода и могуће је написати код који функционише, то би требао бити проблем. Дакле, мој насловни слајд овде, уствари сам имао копију ове слике у веома високој резолуцији А3, али нажалост уништен је у пресељењу куће. Али ово је руком писана белешка на програмском листу из приближно 1945. године, где су наводно неки људи са Универзитета Харвард у САД-у, своју другу конструкцију машине назвали Марк ИИ. Отклањали су грешку неким проблемом, заједничким језиком, али покушавали су да пронађу грешку, а испоставило се да се нешто мало разликовало од хардвера и наводног софтверског проблема.
Дакле, урбани мит је да је око 9. септембра 1945. године тим са Универзитета Харвард раздвајао машину, наишли на нешто што су називали „релеј седамдесет“ - у тим данима програмирање је урађено у физичком смислу, ви навијате код око плоче и тако сте ефикасно програмирали машину - и открили су да овај релеј број седамдесет има нешто с тим, и испада да је стварни израз "буг" настао јер је буквално био мољац - наводно тамо био је мољац закачен између неког дела бакрене жице који је ишао са једног места на друго. А прича каже да легендарна Граце Хоппер за овај наслов, за мој наслов, „први стварни случај проналаска грешке“, цитира цитат.
Али како је Робин нагласио раније у свом првом дијапозитиву, концепт грешке сеже толико далеко колико можемо замислити да људи раде рачунање, концепте попут закрпе. Израз "закрпа" настао је од стварног дела траке који се залепио преко рупе на картици за бушење. Али цела поанта овога је да је појам „отклањање грешака“ произашао из овог концепта проналажења грешке у физичкој машини. И од тада, ми смо користили ту терминологију покушавајући да се бавимо проблемима, било толико колико проблемима кодирања у програму који се не компајлира, већ као програм који не ради добро. А посебно није профилисано само пронађите ствари попут бесконачних петљи које само нигде не иду.
Али имамо и сценарио, па сам помислио да ћу убацити пар смешних слајдова пре него што се упустим у нешто детаљније. Ево класичног цртаног филма, названог КСКЦД на интернету, и карикатуриста има прилично смешне погледе на свет. А ово је о детету званом "Мали Бобби Столови" и наводно су његови родитељи тог младића прозвали Робертом "); СМОЖИТЕ ТАБЕЛУ Ученици; - и то се зове, и врста: „Здраво, ово је школа вашег сина која има проблема са рачунаром“, а родитељ одговара: „Ох, драги, је ли нешто покварио?“ А наставник каже: „Па, на неки начин ", а учитељ пита, " да ли си заиста именовао свог сина Роберта "); ДРОП ТАБЛЕ Студенти; -? “А родитељ каже, „ О да, мали Бобби Столови, ми га зовемо. “У сваком случају, настављају да кажу да су сада изгубили годишњу евиденцију ученика, надам се да сте задовољни. А одговор је: „Па, требали бисте очистити и санирати уносе своје базе података.“ А ја то много пута користим да причам о неким проблемима које имамо у проналажењу ствари у коду, а то да се код често не гледа на податке такође.
Још једна смешна, не знам да ли је ово стварно или не - сумњам да је то подвала - али опет, то се дотиче и моје смешне кости. Неко мења регистарске таблице на предњем делу свог аутомобила, на сличну изјаву која узрокује пад база података у камерама за брзину и тако даље, који снимају регистарске таблице аутомобила. Увек то говорим као да сумњам да је било који програмер очекивао да ће их стварни мотор пронаћи и погодити, али то никада не подцењујте - моћ љутог штребера.
(Смех)
Али претпостављам да ме ово води ка мојој кључној тачки, а то је да смо једном давно могли исправити погрешку и профилити код као обичне смртнике. Али ја увелико сматрам да је то време прошло, а случајно у мом искуству, моје прво - и то ће ме ужасно старити, сигуран сам; Робин, добродошао си да ми се засмејаш због тога - али историјски сам дошао из позадине у доби од 14 година лутајући крај града и покуцао на врата дата центра под називом „Дата Цом“ у Новом Зеланд и питајући да ли могу зарадити џепарац у школи ако дођем касно аутобусом кући, неких 25 км вожње дневно, стављајући папир у штампаче и траке у касете, и само сам генерални администратор. И довољно је знатижељно да су ми дали посао. Али с временом сам успео да се упустим у особље и нађем програмере и схватим да волим кодирање и прошао сам кроз процес извршавања скрипти и скупоцјених послова, што на крају дана још увек кодира. Морате писати скрипте и скупити задатке који изгледају као мини програми, а затим проћи кроз цео процес седења на 3270 терминалу за писање терминала.
У ствари, моје прво искуство било је на телетапском терминалу, који је заправо био физички штампач са 132 колоне. У суштини, мислите на врло стару писаћу машину са папиром који се провлачио кроз њу, јер нису имали ЦРТ цев. А код за уклањање погрешака на том месту био је врло невивијални проблем, тако да сте склони писати сав код руком, а затим се понашати као дактилограф, трудећи се да не дођете до грешака да се увучете, јер је изузетно фрустрирајуће да морате то рећи уредник једне линије отишао је до одређеног ретка, а затим исписао линију и затим је поново откуцао. Али једном приликом, тако смо писали код и тако смо исправљали грешке, и у томе смо били веома, врло добри. У ствари, то нас је присилило на веома добре технике програмирања, јер је била права гњаважа да то поправимо. Али путовање је тада прошло - и сви смо упознати с овим - прошло је од искуства 3270 терминала у мом свету, до Дигиталне опреме ВТ220 на којој сте могли видети ствари на екрану, али опет, управо сте радили исту ствар направили сте на папирној траци неку врсту штампаног формата само на ЦРТ-у, али сте могли лакше да избришете и нисте имали тај звук „дит дит дит дит“.
А онда знате, Висе терминали - попут Висе 150 - вероватно мој омиљени интерфејс за рачунар икада - а затим ПЦ и Мац, а данас модерне ГУИ и ИД-ове који се темеље на вебу. И низ програма кроз то, програмирање у једном и асемблеру и ПИЛОТ и Лого, Лисп и Фортран и Пасцал и језике који могу натерати људе. Али то су језици због којих сте морали да пишете добар код; нису вам дозволили да побегнете са лошим праксама. Ц, Ц ++, Јава, Руби, Питхон - и што више напредујемо у тој фази програмирања, добијамо више сличан скрипту, приближавамо се језику структурираног упита и језицима попут ПХП-а који се заправо користе за позивање СКЛ-а. Поанта да вам кажем да долазим из моје позадине, на многе начине сам била самоука, а они који су ми помогли да учим, научили су ме врло доброј програмској пракси и врло добрим праксама око дизајна и процеса да бих се уверила увести бугги код.
Начин програмирања ових дана, на пример, Структурни језик упита, СКЛ, то је врло моћан, једноставан језик упита. Али претворили смо га у програмски језик и не верујем да је СКЛ икада дизајниран као модеран програмски језик, али ми смо га сковали да то постане. А то уводи читав низ проблема, јер када размишљамо са две тачке гледишта: са становишта кодирања и са становишта ДБА. Врло је лако доћи и представити грешке за ствари попут само лоших програмских техника, лење напора код писања кода, недостатка искуства, класичног пеее-а за кућне љубимце, на пример са СКЛ-овцима који скачу на Гоогле и траже нешто и проналазе веб локацију добио пример и урадио копију и лепљење постојећег кода. А затим копирање лошег кодирања, злоупотребе и стављање у производњу, јер се једноставно догоди да им дате резултате које желе. Имате и других изазова, на пример, ових дана сви журимо ка томе, оно што називамо трком до нуле: покушавамо да све направимо тако јефтино и тако брзо, да имамо сценарио где не запошљавамо ниже -плаћено особље. И то не мислим на безобзиран начин, али ми не запошљавамо стручњаке за сваки могући посао. Некада давно било шта везе са рачунаром била је ракетна наука; била је укључена у ствари које су се гњавиле и биле веома гласне, или су улазиле у свемир или су инжењери били високо квалификовани мушкарци и жене који су дипломирали и имали ригорозно образовање које их је спречавало да раде луде ствари.
Ових дана много људи улази у развој и дизајн и базу података који нису имали више година искуства, нису имали нужно исту обуку или подршку. И тако завршавате сценаријем само традиционалног аматера насупрот стручњака. И ту је позната линија, не могу се заправо сјетити ко је створио цитат, ред иде: "Ако мислите да је скупо ангажирати стручњака за посао, причекајте док не запослите неколико аматера који ће створити проблем и ви морају га очистити. "И тако СКЛ има то питање, и то је врло, врло лако за научити, веома је једноставан за употребу. Али то, по мом мишљењу, није савршен програмски језик. Врло је лако урадити ствари попут изабране звезде одакле год да и извучете све то у програмски језик који вам је угоднији попут ПХП и Руби или Питхон, и користите програмски језик који вам је домаће познат. манипулација подацима, уместо да ради сложенији упит у СКЛ-у. И то много видимо, и тада се људи питају зашто база података ради споро; то је зато што милион људи покушава да купи карту из система за онлине куповину, где то чини одабрана звезда одакле год.
То је заиста екстремни пример, али ви из свега тога схватате. Дакле, да бих стварно преокренуо то место код куће, ево примера који ја много носим. Велики сам љубитељ математике, волим теорију хаоса, волим комплете Манделброт. На десној страни је издање Манделброт сета, за који сам сигуран да смо сви добро упознати. А на левој страни је део СКЛ-а који то заправо и чини. Сада, сваки пут када негде ставим ово на екран, чујем ово „О мој боже, неко је направио Манделброт серију са СКЛ-ом, јеси озбиљан? То је сулудо! “Па, смисао свега тога је да илуструјем оно што сам управо изнео, а то је да, у ствари сада можете програмирати готово све у СКЛ-у; то је врло снажно развијен, моћан, модеран програмски језик. Када је првобитно био језик упита, дизајниран је тако да само добије податке. Дакле, сада имамо врло сложене конструкције и имамо похрањене процедуре, имамо методологију програмирања која се примењује на језик и тако је веома лако због лоше програмске праксе, недостатка искуства, сечења и лепљења кода, ниско плаћено особље које покушава бити високо плаћено особље, људи се претварају да знају, али морају да науче на послу.
Читав низ ствари код којих се профилира код и оно што називамо отклањањем грешака, није толико проналажење грешака који спречавају програме да раде, већ грешке које само штете систему и слабо структуриран код. Када сада погледате овај екран и мислите да је то једноставно, то је баш симпатично и мислите: „Вау, каква сјајна графика, волео бих то покренути.“ Али замислите да то ради на неком делу пословне логике . Изгледа прилично уредно, али говори математички графички приказану теорију хаоса, али када размишљате за шта би се потенцијално могло користити у некој пословној логици, слика врло брзо добијате слику. А да то заиста илуструјем - и жао ми је што су боје обрнуте, то би требало бити црна позадина и зелени текст да би био зелени екран, али то још увек можете да прочитате.
Отишао сам и брзо погледао пример онога што би потенцијално могао да урадиш ако си заиста луд и немаш искуства и долазиш из другачије позадине програмирања и применим сличности Ц ++ на СКЛ, да стварно илуструјем свој став, пре Предајем нашем ученом госту из ИДЕРА-е. Ово је структурирани упит који је написан као Ц ++, али је кодиран у СКЛ-у. И заправо се извршава, али се извршава у периоду од три до пет минута. И повлачи наизглед једну линију података из више база података, више спојева.
Опет, цела поента је у томе што ако немате исправне алате, ако немате исправне платформе и окружења да бисте могли да ухватите ове ствари, и оне уђу у производњу, а онда имате 100.000 људи ударајући систем сваки дан, сат или минут, врло брзо завршите са чернобилским искуством где се велико гвожђе почне топити и закопати у језгро планете, јер тај део кода никада не би требало да уђе у производњу. Извињавам се, ваши системи и ваши алати би требало да то покупе пре него што крене било где у близини - чак и кроз тестни процес, чак и кроз УАТ и интеграцију система, тај део кода треба да се покупи и истакне, а некога треба одвести и говорећи: "Гледај, то је заиста лијепа шифра, али хајде да набавимо ДБА који ће вам помоћи да правилно направите тај структурни упит, јер искрено, то је једноставно гадно." А УРЛ адреса је ту, можете да погледате - назива се најсложенији СКЛ упит који сте икада написали. Јер, верујте ми, то се у ствари компилира, али покреће. А ако то исечете и залепите и само исмевате базу података, то је сасвим нешто за гледање; ако имате алате за гледање базе података, само покушајте да се растопите током периода од три до пет минута, да бисте опозвали оно што је један ред текста.
Дакле, да сумирам, имајући то на уму, целокупна моја позадина кодирања научила ме је да људима можете дати пиштољ, а ако нису опрезни, пуцаће себи у стопало; трик је у томе да им покажете где је безбедносни механизам. Са правим алатима и правим софтвером на дохват руке, након што извршите кодирање, можете да прегледате свој код, можете да пронађете проблеме профилирањем кода, можете да пронађете ефикасне ненамерне грешке које представљају проблеме са перформансама и као што сам рекао раније, некада, то бисте могли да учините гледајући зелени екран. Не можеш више; постоје стотине хиљада линија кодова, постоје десетине хиљада апликација, постоје милиони база података у неким случајевима, па чак ни супер људи то више не могу радити руком. Дословно вам је потребан прави софтвер и прави алати на дохват руке и потребан вам је тим који ће користити те алате како бисте могли да пронађете ове проблеме и да их решите врло брзо, пре него што дођете до тачке, док Др. Истакнуо је Робин Блоор, ствари постају катастрофалне, а ствари се разбуђују, или чешће, оне вас једноставно коштају много долара, пуно времена и труда и уништавају морал и ствари, кад не могу открити зашто ствари трају дуго времена да трчим.
А имајући то у виду, предаћу нашем госту и радујем се што ћу чути како су они решили ово питање. А нарочито демо за који мислим да ћемо ускоро добити. Ериц, вратит ћу се назад.
Ериц Каванагх: ОК, Берт, однеси то.
Берт Сцалзо: ОК, хвала. Берт Сцалзо из ИДЕРА-е, ја сам менаџер производа за наше алате база података. И разговараћу о отклањању грешке. Мислим да је једна од најважнијих ствари коју је Робин раније рекао - и тачно је да је уклањање погрешака напорно и не-тривијално, а када пређете на отклањање грешака у базу података, то је редослед још већег и не-тривијалног - тако да био важан цитат.
ОК. Хтео сам да почнем са историјом програмирања, јер пуно пута видим људе који не отклањају грешке, не користе исправу грешке, само програмирају на било ком језику који користе, и много пута ће ми рећи, „Па, те ствари о исправљању грешака су нове, а ми их још нисмо почели користити.“ И тако, оно што ја радим је да им покажем ову табелу временске траке, неку врсту претповијести, старост, средњи вијек, то је некако рецимо где смо били у погледу програмских језика. И имали смо врло старе језике, почевши од 1951. године, са кодом монтаже, и Лиспом, ФАЦТ-ом и ЦОБОЛ-ом. Затим прелазимо у следећу групу, Паскали и Цс, а затим следећу групу, Ц ++ с, и гледамо где је та упитница - та је упитна тачно тачно око 1978. до можда 1980. Негде у том распону смо имали уређаји за уклањање погрешака који су нам доступни и тако да кажемо: „Хеј, не користим програм за уклањање погрешака, јер то је једна од тих нових ствари“, онда сте сигурно почели да програмирате, знате у 1950-има, јер је то једини начин да се извучете са том тврдњом.
Друга ствар која је смешна у овом графикону је Дез управо је написао коментар о Граце Хоппер, ја сам заправо познавао Граце, тако да је помало смешно. А онда, друга ствар којој сам се смејао је то да је говорио о телетиповима и ја седим тамо и идем: „Човече, то је био највећи скок у продуктивности, када смо прешли с карата на телетипе, то је био највећи скок икада. "Дакле, и програмирао сам на свим језицима овде, укључујући СНОБОЛ, за који нико до сада није чуо, био је то ЦДЦ, Цонтрол Дата Цорпоратион, тако да претпостављам да сам престар за ову индустрију .
Дез Бланцхфиелд: Хтио сам рећи да сте нас страшно остарили .
Берт Сцалзо: Да, кажем вам, осјећам се као дјед Симпсон. Дакле, гледам на исправљање погрешака и постоје различити начини вршења исправке. Могли бисте разговарати о ономе што сви ми сматрамо традиционалним уласком у програм за уклањање погрешака и преласком кода. Али такође, људи ће инструментирати свој код; ту уносите изјаве у свој код и можда произведете излазну датотеку, датотеку у траговима или нешто слично, па на тај начин инструментирате свој код. Рачунао бих да је то отклањање грешака, то је мало тежи начин, али то се рачуна. Али такође, имамо и чувену изјаву о штампању: гледате и људи заправо стављају изјаве о принтању и заправо сам видео алат где - и то је алат за базу података - где ако не знате како да користите алат за уклањање погрешака, притиснете дугме и он ће за вас залепити изјаве за штампање у целом коду, а затим кад завршите, притиснете још једно дугме и оно ће их уклонити. Јер тако много људи отклања грешке.
А разлог за уклањање погрешака је двострук: пре свега, морамо пронаћи ствари које наш код чине неефикасним. Другим речима, обично то значи да постоји грешка у логици или смо пропустили пословни захтев, али оно што јесте јесте да ли код није ефикасан; не ради оно што смо очекивали. Други пут кад идемо на отклањање грешака, ради се о ефикасности и то би могла бити логична грешка, али шта је то, да ли сам исправно поступио, једноставно се не враћа довољно брзо. Сада мислим да је то што је профилер вероватно бољи за други сценариј, а ми ћемо разговарати о дебугерима и профилима. Поред тога, постоји овај концепт даљинске исправке погрешака; ово је важно јер пуно пута ако седите на свом личном рачунару и користите алат за отклањање грешака, који погађа базу података где се код заправо изводи у бази података, заправо радите оно што се назива даљинско отклањање грешака. Можда то не схватате, али то се догађа. И тада је врло често код ових грешака да постоје прекидне тачке, посматрачке тачке, да закорачите и пређете и неке друге уобичајене ствари, које ћу их у трену показати на снимку екрана.
Сада, профилирање: профилирање можете радити на неколико различитих начина. Неки ће рећи да се радно оптерећење хвата и репродукује тамо где све обухвата, а то се рачуна и као профилирање. Моје је искуство било више и боље ако се ради о узорковању. Нема разлога да хватате сваку поједину изјаву, јер неке изјаве могу једноставно да се покрену тако брзо да вас није брига, оно што стварно покушавате да видите јесте, које су оне које се стално изнова приказују, јер предуго су трчали Дакле, понекад профилисање може значити узорковање, а не покретање читаве ствари. И обично ћете добити неку врсту излаза који можете користити, а који би сада могао да буде визуелни унутар ИДЕ развојног окружења, где би вам могао дати сличан хистограм перформанси различитих линија кода, али би такође могао да остане било да производи датотеку у траговима.
Профилри су се први пут појавили 1979. Дакле, и они су дуго времена били ту. Изврсно за проналажење потрошње ресурса или проблема са перформансама, другим речима, ствар ефикасности. Генерално гледано, одвојен је и различит од уређаја за уклањање погрешака, мада сам радио са програмима за уклањање погрешака који раде и једно и друго истовремено. И док су профили за два алата занимљивији, ако сматрам да нема довољно проблема за уклањање погрешака, онда дефинитивно нема довољно профила јер ће се, чини се, један од десет дебугера профилисати. А то је срамота, јер профилирање заиста може да направи велику разлику. Сада, језици база података, као што смо раније говорили, имате СКЛ - и ми смо некако натерали округли затич у квадратну рупу и натерали га да постане програмски језик - и Орацле. То је ПЛ / СКЛ - то је процедурални језик СКЛ - и СКЛ Сервер, то је Трансацт-СКЛ, то је СКЛ-99, СКЛ / ПСМ - јер, мислим, то је процедура похрањени модул. Постгрес му даје друго име, ДБ2 још једно име, Информик, али поента је у томе што су сви присилили конструкције типа 3ГЛ; другим речима, ФОР петље, декларације променљивих и све остале ствари које су стране СКЛ-у сада су део СКЛ-а на тим језицима. И тако, морате бити у стању да отклоните грешку ПЛ / СКЛ или Трансацт-СКЛ баш као што би то радио програм Висуал Басиц.
Сад, објекти базе података, ово је важно јер ће људи рећи: „Па, које ствари морам да отклоним у погрешци у бази података?“ А одговор је: па, шта год можете да похраните у базу података као код - ако радим Т-СКЛ или ПЛ / СКЛ - и чувам објекте у бази података, вероватно је то сачувана процедура или меморисана функција. Али постоје и окидачи: окидач је некако као похрањена процедура, али активира се на неки догађај. Сада ће неки људи у своје окидаче ставити једну линију кода и позвати похрањену процедуру тако да задрже сав свој похрањени код и процедуре, али то је исти концепт: ипак је окидач могао бити оно што покреће цијелу ствар. И тада као Орацле имају нешто што се зове пакет, што је налик библиотеци ако хоћете. Ставите 50 или 100 похрањених процедура у једно групирање, које се зове пакет, тако да је некако попут библиотеке. Дакле, ево уклањања грешака на стари начин; ово је уствари алат који ће вам заправо ући и залепити све ове изјаве о грешкама у коду. Дакле, свугде где видите блок за уклањање погрешака, не уклањајте, покретање аутоматског исправљача грешке и траг, све их је заглавио неки алат. А линије изван тога, што је мањина кода, то је не-ручна метода уклањања погрешака.
А разлог зашто ово изнесем је у томе што, ако покушавате да то урадите ручно, заправо ћете унети више кода за уклањање погрешака који ћете ставити у све ове изјаве за штампање него што их имате са кодом. Иако ово може да функционише, и иако је боље него ништа, ово је веома тежак начин за уклањање погрешака, посебно јер, шта ако је потребно 10 сати да се ова ствар покрене, и где има проблема, у реду је три? Да радим интерактивну сесију за отклањање погрешака, знао бих у линији три - пет минута - хеј, овде постоји проблем, могу престати. Али с овим, морам сачекати да се покрене, све до завршетка и онда морам погледати датотеку у траговима која вероватно садржи све ове изјаве о испису, и покушати пронаћи иглу у сенож. Опет, ово је боље него ништа, али то не би био најбољи начин рада. Ето, то би изгледала та датотека која је настала са претходног слајда; Другим речима, покренуо сам програм, а у овој датотеци с траговима има гомила изјава за штампу и можда нећу моћи да прођем кроз ово и пронађем оно што требам пронаћи. Дакле, опет, нисам баш сигуран да би то требало да радите.
Сада, интерактивни програм за отклањање грешака - и ако сте користили нешто попут Висуал Студио за писање програма или Ецлипсе, имали сте исправљање грешака и користили их на другим језицима - једноставно нисте размишљали да их овде користите са својом базом података. А ту су и алати, попут нашег ДБ Артисан-а и нашег Рапид-а СКЛ-а, овде је Рапид СКЛ, који има исправљање погрешака, а на левој страни можете видети похрањену процедуру која се зове „провери дупликата“. У основи, само ћу отићи и погледати да ли у табели имам више редова са истим насловом филма. Дакле, база података је за филмове. И могли сте да видите са десне стране, у горњој трећини, у средини имам изворни код, имам оно што се назива променљива сата и траке за тресење позива, а затим на дну имам неке излазне поруке. И оно што је овде важно јесте, ако погледате преко те прве црвене стрелице, ако померам мишем преко променљиве, заправо могу да видим која је вредност у тој променљивој у том тренутку док прелазим код. И то је заиста корисно, а онда могу прелазити један ред по један код, не морам рећи извршити, могао бих рећи корак по линији, погледати шта се догодило, прећи на другу линију, да видим шта се догодило, и то радим у бази података. Иако седим на Рапид СКЛ-у на рачунару и моја је база података у облаку, и даље могу радити ту даљинску исправљање погрешака и видети је и контролирати одавде, и радити исправљање погрешака као што бих то урадио са било којим другим језиком.
Следећа стрелица тамо - можете видети мало попут стрелице која показује десно, ка излазу ДБМС-а, ту је тренутно мој показивач - другим речима, закорачио сам и ту сам на тренутак. Дакле, ако кажем „корак поново“, прећи ћу на следећи ред. Сада одмах испод тога видећете црвену тачку. Па, то је тачка прекида, која каже: „Хеј, не желим да прелазим преко ових линија.“ Ако само желим да прескочим све и стигнем до те црвене тачке, могу да притиснем дугме за трчање и оно ће се покренути одавде до краја или до прекида, ако постоје тачке прекида, и онда ће се зауставити и пустити ме да поново одрадим корак. А разлог што је све ово важно и моћно је, јер кад се ја бавим тиме, оно што се догађа у средини, па чак и на дну - али што је најважније у средини - ће се променити и видим вредности из мојих променљивих, Знате свој траг скупа позива, тако да су све те информације тамо приказане док прелазим код, тако да заправо могу да видим и осећам и схватим шта се догађа и како заправо је код радећи у време извршења. И обично могу наћи проблем, ако постоји или ако сам довољно добар да га решим.
У реду, сада ћу говорити о профилару, а у овом случају ово је профил који видим кроз програм за уклањање грешака. Сећате се да сам рекао понекад да су одвојени, а понекад могу бити заједно? У овом случају и поново сам у Рапид СКЛ-у и видим да на левој страни постоји маргина поред бројева линија. И оно што је то, то је број секунди или микросекунди потребних за извршавање сваке линије кода, и то јасно видим, сво своје време проводим у овој петљи ФОР, где бирам све из табеле . И тако, све што се догађа унутар те петље ФОР вероватно је нешто што морам да погледам, и ако успем да је побољшам, исплатиће дивиденде. Нећу постићи никаква побољшања радећи на оним линијама које имају 0.90 или 0.86; нема пуно времена проведеног тамо. Сада, у овом случају, и поново сам у Рапид СКЛ-у, видите како могу да радим профилирање помешано са дебугирањем. Оно што је лепо је што Рапид СКЛ такође омогућава и други начин. Брзи СКЛ омогућава вам да кажете: „Знате шта? Не желим бити у програму за уклањање погрешака, само желим покренути ово, а затим желим да графички или визуелно погледам исту врсту информација. "
И видите да више нисам у програму за отклањање грешака и он покреће програм, а након извршења, даје ми графиконе да ми испричају ствари, тако да видим да имам једну изјаву која изгледа као да се заузима Већина графикона са питу и ако погледам, видим на тој решетки према дну, ред 23, ту је и петља ФОР: он заузима највише времена, он је уствари тај тамноцрвени жвакање свих таблица пита. Дакле, ово је још један начин профилирања. Случајно називамо тог „Аналитичара кода“ у нашем алату. Али у основи је то само профил који је одвојен од исправљача грешака. Неки воле да то раде на први начин, неки воле да то раде на други начин.
Зашто радимо исправљање погрешака и профилисање? Није то зато што желимо да напишемо највећи светски код и добијемо повећану плату - то би могао бити наш разлог, али то није баш разлог зашто то радите - обећали сте послу да ћете нешто урадити исправно, да ће ваш програм бити ефикасан. За то ћете користити алат за уклањање погрешака. Поред тога, пословни крајњи корисници; нису баш стрпљиви: желе резултате чак и пре него што притисну тастер. Требали бисмо читати њихове мисли и учинити све одмах. Другим речима, то мора бити ефикасно. И тако, за то бисмо користили профил. Сада, без ових алата, стварно верујем да сте тај момак у пословном оделу са луком и стрелицом, а пуцате у мету и вежетете очима. Јер како ћете пронаћи како се програм извршава тако што ћете погледати статички код и како ћете схватити која је линија тамо где би заиста провели највише времена у извршењу, опет само гледањем статичког кода? Преглед кода неке од ових ствари може или не мора показати, али нема гаранције да ће их преглед свих кодова пронаћи. Помоћу програма за уклањање погрешака и профила требало би да пронађете све те грешке.
ОК, управо ћу направити прави брзи демо овде. Није ми намера да гурам производ, само желим да вам покажем како изгледа исправљање грешака, јер ће много пута људи рећи, „Никада нисам видео ниједног од ових.“ И изгледа прилично на преклопним слајдовима екрана, али како изгледа када је у покрету? Дакле, ево на мом екрану покрећем наш ДБ Артисан производ; тамо имамо и исправљање погрешака. ДБ Артисан је намењен више за ДБА, Рапид СКЛ је више за програмере, али видео сам програмере који користе ДБ Артисан и видео сам ДБА који користе Рапид. Дакле, немојте се заокупити производом. И ево, имам избор да почнем исправљање грешака, али пре него што покренем програм за исправљање грешака, издвојит ћу овај код да бисте видели како изгледа код пре него што га покренем. Дакле, ево потпуно истог кода који је био на снимку екрана, ово је моја провера дупликата. И желим да откријем ово, па притиснем грешку. И сада треба тренутак и кажете: „Па, зашто вам треба тренутак?“ Сјетите се даљинског уклањања погрешака: уклањање погрешака се заправо дешава на мом серверу базе података, а не на рачунару. Дакле, требало је да пређем и направим сесију тамо, направим ствар на даљинском отклањању грешке, прикачим моју сесију на ту сесију даљинског отклањања грешке и поставим канал за комуникацију.
Дакле, ево моје стрелице, горе је на врху, у првом реду, ту сам код. А ако притиснем тамо трећу икону, што је корак у, видећете да се стрелица управо померила, а ако наставим да је притиснем, видећете да се наставља кретати. Ако бих хтео да се спустим до ове петље ФОР, јер знам да је ту проблем, могу да поставим тачку прекида. Мислио сам да сам то поставио. О, пуцај, имао сам један од мојих тастера за снимање екрана пресликан на исти тастер као и за исправљање погрешака, то је оно што узрокује конфузију. ОК, тако да сам тамо ручно поставио тачку прекида, тако да сада уместо да радим корак, корак, корак, корак док не стигнем тамо, заправо могу само да кажем: „Само напред и покрени ову ствар“, и то ће престати. Примјетите да ме је пребацио доље на мјесто гдје је прекидна точка, тако да сам сада у контексту покретања ове петље, могу видјети на шта су све моје варијабле постављене, што није изненађење, јер сам их иницијализирао све до нуле. А сада, могу ући у ову петљу и почети да гледам шта се догађа унутар ове петље.
Дакле, сада ће то урадити неко одбројавање мојих стана и прелазим мишем преко тог момка и погледам, два, два су већа од једног, тако да ће вероватно урадити следећи део овог кода. Другим речима, нешто је пронашло. Само идем и пустим то да трчи. Не желим да пролазим кроз све овде; оно што желим да вам покажем је да када се направи програм за отклањање грешака, он се завршава баш као и уобичајени програм. Поставио сам тачку прекида, па када сам рекао трчање, само се вратио на следећу тачку прекида. Пустим га да ради до краја, јер оно што желим да видите је да програм за уклањање погрешака не промени понашање програма: кад се заврши у раду, требао бих добити потпуно исте резултате да сам га покренуо не унутар програма за уклањање погрешака.
А с тим ћу суспендирати демо и вратити се јер желимо да осигурамо времена за питања и одговоре. И тако, отворићу га за питања и одговоре.
Ериц Каванагх: У реду, Робин, можда питање од тебе и онда пар из Деза?
Робин Блоор: Да, наравно, мислим да је ово фасцинантно, наравно. Радио сам са оваквим стварима, али никада нисам радио са нечим таквим у бази података. Можете ли ми дати неку идеју за шта људи користе профил? Будући да је то тако, да ли они гледају - јер претпостављам да јесу - гледају на проблеме перформанси, да ли ће вам то помоћи да разликујете када бази података треба времена и када коду треба времена?
Берт Сцалзо: Знате, то је фантастично питање. Рецимо да радим у Висуал Басиц-у, а ја ћу унутар свог Висуал Басиц-а назвати Трансацт-СКЛ или ПЛ / СКЛ. Дозволите ми да урадим ПЛ / СКЛ, јер се Орацле не игра увек добро са Мицрософтовим алатима. Можда сам профилирао свој Висуал Басиц код, а тамошњи профил би могао да каже: „Хеј, назвао сам ову сачувану процедуру и трајало је предуго.“ Али тада могу да уђем у похрањену процедуру и могу да направим профил базе података на сачуваном Поступак и реците: „У реду, од 100 изјава које су овде, ево пет који су проузроковали проблем.“ И тако, можда ћете морати да урадите тим за тагове где морате да користите више профила.
Идеја је да ако вам се икада каже да је проблем са перформансама у вашој бази података, профил базе података може вам помоћи да пронађете игле у пласту сена на којој су изјаве заправо оне где имате проблем. Кажем вам још једну ствар која се појавила са профилирањем: ако имате комад кода који се зове милион пута, али то траје само микросекунду сваки од милион пута, али зове се милион пута, шта би профилер показао, та ствар је трајала током многих јединица. И док је код можда високо ефикасан, можда ћете изгледати и рећи: „Оох, упућујемо овај позив на овај део кода превише често. Можда бисмо га требали звати само толико често, а не сваки пут када обрађујемо плочу “или нешто слично. И тако заправо можете пронаћи тамо где постоји ефикасан код који се пречесто назива, а то је заправо проблем перформанси.
Робин Блоор: Да, то је дивно. Никад то нисам урадио. Видите, наравно, када сам имао проблема са базом података, било је као да бих се на овај или онај начин бавио базом података или се бавио кодом; Никада се не бих могао истовремено суочити са обојицом. Али тамо, опет, нисам урадио … Никада нисам био умешан у прављење апликација где смо чували процедуре, па претпостављам да никада нисам наишао на проблеме који су ме дирали, идеја да ви Поделио бих код између базе података и програма. Али тако, учини све - претпостављам да ће одговор бити да, али ово је део активности развојног тима, када на овај или онај начин покушавате да поправите нешто што је покварено или можда покушавате да донесете ново апликација заједно. Али да ли се све то прилагођава свим осталим компонентама које бих очекивао у окружењу? Да ли могу да очекујем да бих могао да снимим ово заједно са свим својим тест пакетима и свим тим осталим стварима које бих радио и са својим стварима у вези са управљањем пројектима, да ли је тако све ово заједно?
Берт Сцалзо: Да, то може постати дио било ког структурираног процеса у којем ћете радити на програмирању или развоју. И смешно је, прошли тједан сам имао клијента који је правио веб апликацију, а њихова база података је, историјски, била мала, па чињеница да нису били баш добри програмери их никада није повредила. Па, њихова база података је током година расла, и сада је потребно 20 секунди на веб страници, између, када кажете: „Пријавите се и дајте ми неке податке да видим“ и када се екран заиста појави, и сада је то проблем са перформансама И знали су да проблем није ни у било којој њиховој Јави или неком другом месту. Али имали су хиљаде сачуваних процедура и зато су морали да започну профилисање ускладиштених процедура да би открили зашто је овој веб страници потребно 20 секунди да би се појавило? И у ствари смо установили да се у једној од њихових избраних изјава придружили картезијански људи и да то нису знали.
Робин Блоор: Вов.
Берт Сцалзо: Али неко ми је једном рекао, "Па како су могли да се придруже картузијану, а не знају?", А ово ће звучати заиста ужасно; понекад програмер који није баш удобан са СКЛ-ом направи нешто попут придруживања картезијанцу, али тада ће ми вратити само прву плочу, тако да знам да имам нешто, а треба ми само прва. И тако, они не схватају да су управо вратили милијарду записа или гледају милијарду записа, јер су добили оно што их је занимало.
Робин Блоор: Вов, знам, тако се зове - ето, о чему се Дез ишао, у смислу људи који нису баш тако вешти колико би требали бити, знате. Ако сте програмер, требали бисте знати какве су импликације издавања било које наредбе. Мислим, заиста, нема оправдања за тај ниво глупости. Такође претпостављам да сте, на овај или онај начин, само језички агностик у вези с тим, јер се све фокусира на страну базе података. Да ли сам у праву? Да ли је то исто, шта год да користите на страни кодирања?
Берт Сцалзо: Апсолутно, ово можете учинити у Фортрану или Ц или Ц ++. У ствари, на неким Уникима чак можете то учинити и за њихове скриптне језике; они заправо пружају исте алате. А онда желим да се вратим на тренутак за оно што сте рекли без изговора. Даћу програмерима једну паузу, јер не волим бацати програмере испод аутобуса. Али проблем је заиста академско окружење, јер када идете да научите како да будете програмер, учи вас да записујете истовремено. Ниси научен сет размишљања, а то је оно што структурирани језик упита или СКЛ ради са скуповима; зато имамо унију, пресек и минус оператора. А понекад је врло тешко да особа која никада није размишљала у вези са сетовима, одустане, пусти се у обраду снимака и обрађује са сетовима.
Робин Блоор: Да, с тобом сам. Мислим, схватам сада, то је питање образовања; Мислим да је то потпуно питање образовања, мислим да је природно да програмери размишљају процедурално. А СКЛ није процедурални, већ је декларативан. Ви заправо само кажете: "Ово је оно што желим и није ме брига како то радите", знате? Док с програмским језицима често завирујете рукаве и падате у детаље чак и управљања бројевима, док радите петљу. Предаћу се …
Берт Сцалзо: Не. У реду, настави.
Да, хтео сам да кажем да сте навели још један пример да ће профилер добро ухватити, као што се и даље догађа с овом евиденцијом у исто време. Понекад програмер који је добар у логици снимања, не може смислити како да ради СКЛ програм. Па, рецимо да прави две петље ФОР и у основи чини спајање, али то ради на страни клијента. Дакле, он има исти ефекат као придруживање, али то ради и сам, и профил би то ухватио, јер бисте вероватно на крају потрошили више времена радећи спајање ручно, него што серверу базе података то омогућава уместо вас.
Робин Блоор: Да, то би била катастрофа. Мислим, само би се бацио наоколо. Бацање је увијек лоше.
У сваком случају, прећи ћу на Дез; Сигуран сам да има неколико занимљивих питања.
Дез Бланцхфиелд: Хвала, да, да. Придружићу вам се не бацајући програмере испод аутобуса. Мислим, провео сам превише година у животу и сам био кодер, на свим нивоима, знате да ли је као што сте рекли, седећи у командној линији Уник машине, а у неким случајевима сам чак био и умешан у неколико различитих портова Уника од једне хардверске платформе до друге. И можете замислити изазове које смо тамо имали. Али стварност је следећа: картица за излазак из затвора за сваки кодер и скриптер на свету. Ракетна наука, буквално, писати заиста уско, сваки пут, ракетна наука. И познате приче људи попут Денниса Ритцхиеја и Бриана Кернахана који самостално раде на неким деловима кода, а затим прелазе на чету за преглед кода уз кафу и открију да су написали потпуно исти део кода, у потпуно истом програму, на потпуно исти начин. И они су то урадили у Ц. Али, тај пуристички ниво програмирања постоји веома ретко.
Чињеница је да на дневној бази постоје само 24 сата дневно, седам дана у недељи, а ми једноставно морамо завршити ствари. И тако, када су у питању не само традиционални програмери, ДБА-и, и кодери, и сцриптери, и сисадмин, мрежни администратори, и безбедносно особље, и све до ових дана са подацима о грађанима; Чујемо, сви само покушавају да раде свој посао. И зато мислим да је сјајно од свега што сам волео ваш демо и волео сам оно што сте нам оставили тамо, пре само тренутак, разговарајући са Робином о чињеници да ово има одређено - можда не толико ниша - али широки простор који се односи на поправљање кода и СКЛ-а и база података. Али био сам јако узбуђен кад сам чуо да кажете како бисте могли да га покуцате скрипту шкољке и пронађете неке проблеме, јер знате, у данашњем дану и добу увек радимо на најнижу цену за све.
Разлог зашто негде можете купити мајицу од 6 долара је тај што је неко изградио систем довољно јефтин да уствари производи и отпрема и логистички испоручује, продаје и продаје на мало и узима путем интернета плаћања да бисте добили ту мајицу од 6 долара. А то се не дешава ако вам се људи плаћају 400.000 долара годишње да пишу код на савршен начин; то је само цео развој. Дакле, та тачка, претпостављам да је једно од питања које бих вас заиста волео да нам дате само мало више увида у томе шта је ширина и досег типа људи које тренутно видите који користе ове алате за профил код и тражите проблема са перформансама? У почетку, историјски, одакле долазе? Јесу ли то биле велике инжењерске куће? И онда, ако кренете напријед, да ли је то тачно, мислим ли да мислим да све више и више компанија имплементира овај алат или ове алате како би покушали да помогну кодерима, за које знају да само раде ствари како би завршили посао. и склонити је кроз врата? А понекад нам треба карта за излазак из затвора? Да ли сам у праву мислећи да смо историјски имали више инжењерског фокуса и развоја? То сада добијамо мање, као што је Робин рекао, академски приступ, а сада је самоук, или сечи и залијепи код, или једноставно гради ствари? И да ли се то подудара са врстом људи који сада узимају производ?
Берт Сцалзо: Да, тачно. Даћу вам сасвим конкретан пример, ми само желимо да посао буде завршен, јер пословни људи не желе савршенство. То је попут компјутерске игре у шаху: шаховска игра не тражи савршен одговор; тражи одговор који је довољно добар у разумном року, тако да то и програмирамо. Али оно што сада проналазим је да већина људи уместо да каже да желе профиларе као део тестирања јединице - тако бих и урадила, јер то не доживљавам као губљење времена - шта се дешава је сада када се то ради касније, понекад, током интеграционог тестирања или тестирања отпорности на стрес, ако имамо среће. Али већином је то део ескалације, где је нешто пропало у производњи, неко је време трајало, можда чак и радило годинама, а сада то не ради добро, а сада ћемо то профилисати. И чини се да је то сада чешћи сценарио.
Дез Бланцхфиелд: Да, и мислим да је појам „технички дуг“ вероватно више него познат; Знам Робина и сигурно јесам. Мислим да је за мене концепт техничког дуга ових дана, посебно у окретним приступима развоју и изградњи система, сасвим стварна ствар, и ми то заправо и водимо рачуна у пројектима. Знам, мислим, имамо сопствене пројекте као што су Медиа Ленс и други, где се свакодневно дешава кодирање и разне ствари широм Блоор Групе. И кад год нешто градимо, ми некако посматрамо, гледам то и увек посматрамо са становишта онога што ће ме коштати да то исправим сада, насупрот томе да ли могу то да схватим у могу га извадити тамо, а онда гледати и видети да ли ће се ова ствар покварити. И наследити овај технички дуг за који знам да ћу касније морати кружити и поправити.
И мислим, то сам урадио у последњих седам дана: Написао сам пар алата и скрипти, написао сам пар комада језика Питхон-а и распоредио сам га у задњи део Монгоа, правећи сигуран да је леп и чист и сигуран, али једноставно добија упит који ми треба обавити, знајући да ми треба та функција да радим, да додјем до веће слагалице; ту је моја права бол. Тако да имате технички дуг и мислим да ово сада није само повремена ствар, мислим да је то део ДНК који се развија. Људи само - не безобразно - само прихватају да је технички дуг уобичајен начин издавања и једноставно га морају покренути. Тамо имате технички дуг. И мислим да је сјајна ствар у ономе што сте нам показали на демонстрацији то што можете буквално профилисати и гледати колико времена нешто треба да ради. И то ми је вероватно једна од најдражих ствари. Мислим, заправо сам направио алате за профилирање - користили смо алате у Сед и Леку и Орцу да бисмо покренули наш код и видели где су петље, пре него што су доступни овакви алати - и када сте направили код за покретање и преиспитајте свој код, постаћете веома добри у томе што нећете морати да прегледавате сопствени код. Али то сада није случај. Имајући то у виду, постоји ли одређени тржишни сегмент који то заузима више него било који други? Видети као маса -
Берт Сцалзо: О да, имам - направићу аналогију за вас и показаћу вам да то раде не-програмери стално. "Јер ако икада предајем класу за дебуку и профилирање или сеансу, питаћу људе:" ОК, колико људи овде улази у Мицрософт Ворд и намерно никада не користи проверу правописа? И нико не диже руку, јер за писање докумената сви знамо да можемо да направимо грешке на енглеском и зато сви користе алатку за проверу правописа. И рекао сам: "Па, како то да када у ИДЕ пишете текст као што је Висуал Басиц, не користите исправу? То је иста ствар, то је као провера правописа. "
Дез Бланцхфиелд: Да, у ствари, то је сјајна аналогија. Нисам баш размишљао о томе, морам признати да заправо радим нешто слично са неколико алата које користим. У ствари, један ОДФ, мој омиљени код Ецлипсе-а, је само сечење и лепљење кода тамо и тражење ствари које су одмах истакнуте и схватање да сам написао погрешку у неком класном позиву. Али, али сада је занимљиво са оваквим алатом то можете учинити у реалном времену, за разлику од тога да се вратите и погледате касније, што је некако лепо кад бисте га ухватили унапред. Али да, то је сјајна аналогија само стављања текста у програм за обраду текста, јер је то интересантан позив за буђење, само схватите да сте направили неке погрешке при упису или чак граматичку грешку, зар не?
Берт Сцалзо: Тачно.
Дез Бланцхфиелд: Дакле, видите ли више потешкоћа, ваљда, мислим, последње питање од мене, пре него што одем на наша питања и питања, можда, за наше полазнике. Ако бисте хтели да дате неку врсту препоруке око приступа томе - претпостављам да је то реторичко - да ли је то случај да рано уђете и то примените док развијате, пре него што се развијате? Или је случај да углавном градите, крећете се, нешто састављате, а затим уђете и касније то профилирате? Претпостављам да је случај раније доћи и провјерити да ли је код чист унапријед. Или је случај да би они требали размотрити овај део свог посла након размештања?
Берт Сцалзо: У идеалном случају, они би то урадили унапред, али зато што су сви у свету гужве у којој морају тек да заврше ствари, склони су да то не ураде док не наиђу на проблем са перформансама који не могу да реше додавањем више процесора и меморије на виртуелну машину.
Дез Бланцхфиелд: Да. Па, уствари сте споменули нешто занимљиво, ако могу брзо? Прије сте поменули да се то може покренути било где и да може да разговара са базом података са задње стране. Дакле, ово је у складу с бимодалним концептом о којем сада причамо, о облаку у просторији / ван простора, и по изгледу ствари, на крају дана, ако може разговарати са задњим крајем и видети код, то баш и не занима, зар не?
Берт Сцалзо: Тачно, да, можете то покренути у облаку.
Дез Бланцхфиелд: Одлично, јер мислим да управо тамо креће наш нови храбри свијет. Дакле, Ериц. Вратићу се сада и видећу да овде имамо неколико питања и желим да наши полазници и даље остану с нама, иако смо прошли сат.
Ериц Каванагх: Да, има неколико људи тамо, само ћу брзо прокоментарисати: Берт, мислим да је метафора, аналогија коју дајеш коришћењу провере правописа искрено сјајна. То је достојно блога или два, сасвим искрено, јер је то добар начин да уоквирите контекст онога што радите и колико је то драгоцено и како би заиста требало бити најбоља пракса за коришћење исправљача грешака редовно, зар не? Кладим се да добијете неке главе главом када га избаците напоље, зар не?
Берт Сцалзо: Апсолутно, јер оно што им кажем је: „Зашто да покренем правописну проверу својих докумената? Не желим да се срамотим због глупих правописних грешака. "Па, не желе да их срамотају глупе грешке у кодирању!
Ериц Каванагх: Тачно. Да заиста. Па, људи, сагорели смо овде сат и пет минута, велико хвала свима вама на вашем времену и пажњи. Ми архивирамо све те веб четове, слободно се вратите било када и погледајте их. Најбоље место за проналажење тих веза је вероватно тецхопедиа.цом, па ћемо ово додати овде на ову листу.
И с тим ћемо се опростити, људи. Још једном, одличан посао, Берт, захваљујући нашим пријатељима из ИДЕРА-е. Разговараћемо са тобом следећи пут, разговараћемо с вама следеће недеље. Брини се! Ћао.
