Paket servisi: Ev sahibi Eric Kavanagh, Dr. Robin Bloor, Dez Blanchfield ve IDERA’s Bert Scalzo ile veritabanı hata ayıklama ve profillemeyi tartıştı.
Şu anda giriş yapmadınız. Lütfen videoyu görmek için giriş yapın veya kaydolun.
Eric Kavanagh: Pekala bayanlar baylar, Çarşamba günü saat 4:00, tabii ki bu demek oluyor.
Robin Bloor: Seni duyamıyorum Eric.
Eric Kavanagh: Birkaç gün önce oradaydım, o yüzden yalnız değilsin. Ama bu yüzden bugünkü konu gerçekten ilginç şeyler. Yapmak istediğiniz türden bir şey, şirketinizde arka planda gerçekleşiyor, siz yapan kişi olmadığınız sürece, bu durumda uygun şekilde yaptığınızdan emin olmak istersiniz. Çünkü hata ayıklama hakkında konuşuyorlardı. Hiç kimse hataları sevmez, hiç kimse yazılım çalışmayı bıraktığında sevmez - insanlar sinirlenir, kullanıcılar düşmanca davranır. Bu iyi değil. Yani, "Hızlı Tepki: Veritabanında Hata Ayıklama ve Kurtarmaya Profil Verme" hakkında konuşacaktık.
Gerçekten senin hakkında bir şey var, beni vurmak, elbette @ eric_kavanagh.
Bu yıl sıcak. Ve hata ayıklama ne olursa olsun sıcak olacak. Gerçekten de bu sorunlardan biri olacak, asla gitmeyecek, bu konuda ne kadar iyi olursak olalım, her zaman sorun olacak, bu yüzden anahtar, bu sorunları çabucak çözebileceğiniz yere nasıl gidersiniz? İdeal olarak, çok fazla yanlış gitmeyen harika programcılar, harika ortamlar var, ancak eskilerin söylediği gibi, “Kazalar ailelerin en iyisi olur”. Aynı şey organizasyonlar için de geçerli. Öyleyse, bu şeyler olacak, olacak, soru şu: onunla başa çıkmak ve bu problemleri çözmek için sizin çözümünüz ne olacak?
Robin Bloor'dan, o zamanlar kendi Dez Blanchfield'ımızdan aşağıdan, ve elbette, iyi arkadaşımız Bert Scalzo, IDERA'dan duyuyorum. Ve aslında, anahtarları Robin Bloor'a vereceğim, alıp götüreceğim. Zemin senindir.
Robin Bloor: TAMAM. Bu, enteresan bir konu. Dez'in muhtemelen hata ayıklama ile ilgili gerçek teknikler ve savaş hikayeleri hakkında devam edeceğini düşündüğümden, sadece bir arka plan tartışması yapılacağını düşündüm. Bunu uzun zamandır yaptım ve bir kodlayıcı oldum, bu yüzden onun gibi ve açık sunum fikri hakkında lirik balmumuna başlamak için bu sunumla neredeyse baştan çıkarmıştım ama bunu başka birine bırakacağımı düşündüm.
Heres ünlü böceklerin bir listesi ve bunların çoğu en azından 100 milyon dolar olan son iki maliyet hariç, temelde herkesin en üst listesine giriyor. Bunlardan ilki, Mars İklim Orbiteriydi, uzayda kayboldu ve insanların metrik birimlerini (gülüyor) ayakları ve inçleriyle karıştırdığı bir kodlama sorunu yüzündendi. Ariane Five Flight 501, kullanılmakta olan bir motor ile fırlatıldığında roket çalıştırması gereken bilgisayarlar arasında bir uyumsuzluk vardı. Birden fazla bilgisayar hatası, patlayan roket, haber başlığı. 1982 yılında Sovyet gaz boru hattının gezegen tarihindeki en büyük patlama olduğu söyleniyor; Olup olmadığından emin değilim. Ruslar bazı otomatik kontrol yazılımları çaldılar ve CIA bunu yapacaklarını ve içine böcek koyacağını fark etti ve Sovyetler bunu test etmeden uyguladılar. Yani, bir boru hattını havaya uçurdu, bunun eğlenceli olduğunu düşündü.
Morris solucanı, birdenbire her tarafa dolanan hızlı bir solucan haline gelen kodlayıcı bir deneydi - görünüşe göre 100 milyon dolar değerinde hasara yol açtı; Bu elbette bir tahmin. Intel, 1993 yılında Pentium çipinde matematik talimatı olan ve 100 milyon doların üzerinde bir maliyeti olan bir matematik yongasıyla ünlü bir hata yaptı. Apple Haritalar programı muhtemelen Apple'ın şimdiye kadar yaptığı en kötü ve en feci lansmanıdır. Kullanmaya çalışan insanlar, birileri 101 boyunca sürüyorlardı ve Apple Haritasının San Francisco Körfezi'nin ortasında olduklarını söylediklerini keşfettiler. Böylece insanlar Apple Maps uygulamasına iLost olarak bakmaya başladılar. 1990'daki en uzun kesintimiz - bunun gibi bir şeyin maliyeti açısından sadece ilginç - AT&T yaklaşık dokuz saat sürdü ve uzun mesafeli aramalarda yaklaşık 60 milyon dolar tuttu.
Ve ben bir İngiltere sigorta şirketindeydim ve veritabanı, veritabanının yeni bir versiyonunu uyguladılar ve verileri silmeye başladılar. Bunu son derece iyi hatırlıyorum, çünkü daha sonra bir çeşit veritabanı seçimine katılmaya çağrıldım. Ve veritabanının yeni bir versiyonunu almaları çok ilginçti ve veritabanının tüm testlerini geçen yeni versiyonları için yaptıkları bir test bataryası vardı. Verileri silmek için gerçekten karanlık bir yol buldu.
Neyse, işte bu. Id empedans uyuşmazlığı ve yayınlanan SQL hakkında konuşmak düşündüm. İlişkisel veritabanlarının tablolarda ve kodlayıcılarda veri depolaması ilginçtir, tablolarda gerçekten çok iyi eşleşmeyen nesne yapılarında verileri değiştirme eğilimindedir. Ve bu nedenle, empedans uyumsuzluğu denilen şeyi elde edersiniz ve birileriyle bir şekilde veya başka bir şekilde ilgilenmek zorunda kalırsınız. Fakat gerçekte ne olduğu, çünkü bir model, kodlayıcı model ve veri tabanı başka bir model özellikle uyumlu değil. Endüstri birlikte çalışan, çok komik olduğunu düşündüğüm şeyleri yapsaydı, gerçekleşmeyecek böceklerle karşılaşıyorsunuz. Bu yüzden, temel olarak, kodlayıcılar tarafında, hiyerarşilere sahip olduğunuzda türleri olabilir, kümelere yol açabilir, zayıf API yeteneği olabilir, şeyleri sadece veritabanıyla etkileşime girerek ifade eden birçok şey olabilir. Ama benim için en çok ilgimi çeken şey, gerçekten ilginç; Kodlayıcıların ve veritabanlarının birbirleriyle çalışacak şekilde bir tür empedans olan bu SQL engeline sahip olmanız beni hep şaşırttı. Dolayısıyla, SQL veri tanıma özelliğine sahiptir ve seçim, proje ve birleştirme için DML özelliğine sahiptir. Bununla veritabanından veri alma konusunda çok fazla yetenek atabilirsiniz. Ama bir şeyler yapmak için çok az matematik dili var. Bundan ve bundan biraz var ve zamana bağlı çok az şey var. Ve bu nedenle, SQL veriyi almaktan hoşlanıyorsa kusurludur. Bu nedenle, veritabanı çalışanları veri tabanında yaşamak için saklı yordamlar oluşturdular ve orada saklı yordamların nedeni, gerçekten bir programa ileri geri veri atmak istemiyor olmanızdı.
İşlevsellikten bazıları son derece verilere özgü olduğundan, yalnızca referans bütünlüğü ve basamaklı silmeler ve bunun gibi şeyler değildi; veritabanı, bir veritabanı için işlevsellikten kaynaklanan tüm ani işlemlerle ilgileniyordu; uygulama kodlayıcı ve veritabanı arasında bölünmüş olabilir. Ve bu, bazı işlevleri yerine getirme işini gerçekten zorlaştırdı ve bu nedenle daha fazla hataya açık hale getirdi. Yani, bu veritabanı oyununun bir yanıdır, çünkü ilişkisel veritabanlarına dahil olduğum için, örneğin birçok uygulamada bulunduğunuz anlamına gelir, çünkü kodlardan ayrı olarak ele alınan saklı yordamlarda yer alan çok fazla sayıda kod vardır. uygulamalarda oturur. Ve yapması gereken çok garip bir şey gibi görünüyor, çeşitli şeyler yapmakta oldukça akıllıca olması gerekiyordu.
Id'in veritabanı performansı hakkında da konuştuğunu düşündüm, çünkü performans hataları genellikle hata olarak kabul edilir, ancak temelde CPU'da, bellekte, diskte, ağda bir tıkanıklık yaşayabilir ve kilitleme nedeniyle performans sorunlarına sahip olabilirsiniz. Buradaki fikir, kodlayıcının performans konusunda gerçekten endişelenmesine gerek duymayacağı ve veritabanının aslında oldukça iyi bir performans göstereceği şeklinde olacaktır. Kodlayıcının bilmesi gerekmeyecek şekilde tasarlanması gerekiyordu. Ancak, kötü veritabanı tasarımı alırsınız, kötü program tasarımı alırsınız, iş yükü karışımında eşzamanlılık elde edersiniz, bu da performans sorunlarına yol açabilir. Yük dengeleme elde edersiniz, kapasite planlaması yaparsınız, veri büyümesi - veritabanının durmasına veya yavaşlamasına neden olabilir. İlginç bir şey, veritabanları neredeyse tamamen dolduğunda yavaşlar. Üstelik çoğaltma, çoğaltma ve yedekleme ve kurtarma işlemlerine gerek duyma konusunda veri katmanları sorunu yaşayabilirsiniz. Neyse, bu genel bir bakış.
Söylemek istediğim tek şey, veritabanı hata ayıklamanın sadece zahmetli ve önemsiz olabileceğidir - ve bunu çok fazla yaptığım için söylüyorum - ve sık sık karşılaştığım hata ayıklamadaki tüm durumlarını keşfedeceksiniz. , gördüğünüz ilk şey bir karmaşa. Ve bu karmaşanın nasıl ortaya çıktığını bulmak için karmaşadan denemek zorundasınız. Ve çoğu zaman bir veritabanı sorununa baktığınızda, tüm baktığınız bozuk verilerdir ve “Bu nasıl oldu?” Diye düşünüyorsunuz.
Her neyse, muhtemelen çıktığımdan daha fazla bilgelik söyleyecek olan Dez'e geçeceğim. Topu nasıl geçireceğimi bilmiyorum Dez.
Eric Kavanagh: Onu geçeceğim, bekle, bekle.
Otomatik ses: Katılımcı hatları kapatıldı.
Eric Kavanagh: Tamam, bir saniye bekle, Dez'e topu vereyim.
Dez Blanchfield: Teşekkürler Eric. Evet, Dr. Robin Bloor, gerçekten en haklısınız: bu bir konudur, pardonu affederseniz ömür boyu sürecek bir böceği, özür dilerim bu konuda kendime yardımcı olamadım. Umarım ilk ekranımı görüyorsunuz, yazı tipi boyutu sorunu için özür dilerim. Hataların konusu, deneyimlerime göre, çoğu zaman günlük bir konferans. Bu çok geniş ve geniş bir konudur, bu yüzden odaklanmayı iki kilit alana, özellikle de bir hata olarak düşündüğümüz kavramına, ancak bir programlama sorununa odaklayacağım. Sanırım bugünlerde bir hata ortaya koyan böcekler, uzun süredir devam etmekte olan böcekler olmasına rağmen, genellikle bütünleşik geliştirme ortamları tarafından ele geçirildiğini düşünüyorum. Ancak çoğu zaman daha çok bir profil kodlaması ve işlev kodunu yazmak mümkün, bu bir hata olmalı. Yani, başlığım buradaki slayt, aslında A3 yüksek çözünürlükte bunun bir kopyasını aldım, fakat ne yazık ki evin bir taşınmasıyla imha edildi. Fakat bu, 1945'lerden kalma bir programlama kağıdında, ABD'deki Harvard Üniversitesi'ndeki bazı halkların Mark II adlı bir makinenin ikinci yapısını yaptığı sözde yazılı bir not. Ortak bir dilde bazı sorunları ayıklıyorlardı, ancak bir hata bulmaya çalışıyorlardı ve donanımdan ve sözde yazılım sorunundan biraz farklı bir şey ortaya çıktı.
Yani, şehir efsanesi yaklaşık 9 Eylül yuvarlaktırinci, 1945 Harvard Üniversitesindeki bir ekip bir makineyi ayırdı, “yetmiş röle” adı verilen bir şeye rastladılar - o günlerde programlama fiziksel bir şekilde yapıldıysa, bir tahtanın etrafına kod sardınız ve bu şekilde makine - ve bu röle sayısının yetmiş olduğunu bulmuşlar, içinde yanlış bir şeyler olduğunu ortaya çıkardılar ve “böcek” fiili terimi ortaya çıktı, çünkü kelimenin tam anlamıyla bir güve oldu - sözde, bir parça bakır telin arasında geçen bir güve vardı bir yerden diğerine. Hikaye, efsanevi Grace Hopper'ın bu altyazı olarak benim başlığımdan “ilk bulunmuş olan bir hatanın ilk örneği” olduğunu gösteriyor.
Ancak Robin, ilk slaydında daha önce de vurgulandığı gibi, bir böcek kavramı, hesaplama yapan insanların, bir yama gibi kavramları hayal edebildiğimiz kadar geriye uzanıyor. “Yama” terimi, delikli karttaki bir delikten bantlanan gerçek bir bant parçasından geliyordu. Fakat bunun asıl amacı, “hata ayıklama” teriminin fiziksel bir makinede bir hata bulma kavramının ortaya çıkmasıdır.Ve o zamandan beri, bu terminolojiyi, derleme yapmayan bir programdaki kodlama konularıyla değil, iyi çalışmayan bir program olarak, sorunlarla başa çıkmaya çalışmak etrafında kullandık. Ve özellikle de henüz bir yere ayrılmayan bitmeyen döngüler gibi şeyler bulmak için henüz profillenmedi.
Ama aynı zamanda bir senaryomuz var ve sanırım biraz daha detaylara girmeden önce Id'nin birkaç komik slayt yerleştirdiğimi sanıyordum. Heres, internette XKCD adı verilen klasik çizgi film ve çizgi filmcinin dünya hakkında oldukça komik görüşleri var. Ve bu, “Küçük Bobby Tables” adında bir çocukla ilgili ve sözde ebeveynleri bu genç çocuğa Robert adını verdiler; DROP TABLO Öğrencileri; - ve denir ve “Merhaba, bu senin oğullarının okulu bazı bilgisayar sorunlu” diyor ve veli cevap veriyor, “Ah canım, bir şey mi kırdı?” Ve öğretmen, “Eh, bir şekilde, ”ve öğretmen,“ gerçekten oğluna Robert adını verdi mi? ”; DROP TABLO Öğrenciler; -? ”Ve ebeveyn,“ Ah evet, küçük Bobby Tablolar diyoruz. ”Diyor. Her neyse, artık yıllarca öğrenci kayıtlarını kaybettiklerini söylemeye devam ediyorlar, umarım mutlusundur. Yanıt ise “Eh, veritabanı girişlerinizi temizlemeli ve dezenfekte etmelisiniz.” Ve kodda bir şeyleri bulmakta yaşadığımız bazı sorunlardan bahsetmek için defalarca kullanıyorum, çoğu zaman kod verilere de bakmıyor. .
Başka bir komik olan, bunun gerçek olup olmadığını bilmiyorum - bir parolasından şüpheleniyorum - ama yine komik kemiğime de dokunuyor. Biri araçlarının önündeki plakayı değiştiriyor, benzer bir ifadeyle veritabanlarının hız kameralarında düşmesine neden oluyor ve bu da arabaların plakasını çekiyor. Ve ben her zaman, herhangi bir programcının gerçek bir motorlu taşıt tarafından kodlarının çarpılmasını ve çalıştırılmasını beklediğinden şüpheliyim, ama asla - bu kadar küçümsemediğim bir şey - kızgın bir ineğin gücünü.
(Kahkaha)
Fakat bu bana kilit noktama yol açıyor, sanırım, ve bu, bir zamanlar, sadece ölümlüler olarak hata ayıklayabildiğimizi ve profil kodlayabileceğimizi gösteriyor. Ama o zamanın geçtiği görüşünü ve deneyimlerime göre, ilk önce benim görüşümden çok daha fazlasıyım - ve bu beni korkunç yaşlandırıyor, eminim; Robin, bunun için benimle dalga geçmeyi memnuniyetle karşılıyorsunuz - ama tarihsel olarak, 14 yaşında bir kasabadan aşağıya inip, Yeni Zelanda'da “Data Com” adlı bir veri merkezinin kapısını çalıp, Okuldan geç saatlere kadar eve geç saatlerde otobüsle, her gün yaklaşık 25 km uzaklıktaki bir otobüse binerek, ers'e kağıt koyarak, teyp sürücülerine bantlar koyarak ve sadece genel bir yönetici olarak harcadım. Ve merakla yeterince bana bir iş verdi. Ancak zamanla kendimi işe koyma ve programcıları bulmayı başardım ve kodlamayı çok sevdiğimin farkına vardım ve günün sonunda hala kod olan senaryolar ve toplu işler yürütme sürecinden geçti. Mini programlar gibi görünen senaryolar ve toplu işler yazmanız ve ardından 3270 terminal yazım kodunda el ile oturma işleminin tümünden geçmeniz gerekir.
Aslında benim ilk deneyimim, aslında 132 sütun fiziksel olan bir teletype terminalinde oldu. Esasen, içinde kaydırılmış kağıt bulunan çok eski bir daktilo gibi düşünün, çünkü bir CRT tüpü yoktu. Ve bunun üzerine hata ayıklama kodu çok önemsiz bir konuydu, bu yüzden tüm kodunuzu elle yazma eğilimindeydiniz ve sonra da bir daktilo gibi davranıyorsunuz, gizlice hata yapmamak için elinizden gelenin en iyisini yapıyorlardı, çünkü bunu söylemek çok sinir bozucuydu. belirli bir satıra gidilecek tek satır editörü, sonra satır sonra tekrar yazın. Ancak bir zamanlar kod yazdığımız ve hata ayıkladığımız ve bu konuda çok iyi olduğumuz şey oldu. Ve aslında, bizi çok iyi programlama tekniklerine zorladı, çünkü düzeltmek için gerçek bir güçlüktü. Fakat yolculuk sonra geçti - ve hepsi buna aşinaydı - dünyamdaki 3270 uçbirim deneyiminden, ekrandaki şeyleri görebileceğiniz Digital Equipment VT220'ye gitti, ama yine de, aynı şeyi yaptınız kâğıt kaset üzerinde bir CRT formatında ed formatı var, ancak daha kolay silebildiniz ve “dit dit dit dit” sesini alamadınız.
Ve sonra biliyorsunuz, Wyse terminalleri - Wyse 150 gibi, muhtemelen bir bilgisayarla şimdiye kadarki en sevdiğim arayüz - sonra PC ve ardından Mac ve bugünlerde web tabanlı modern GUI'ler ve kimlikler. Ve bir dizi program, bir programda programlama ve PILOT ve Logo ve Lisp ve Fortran ve Pascal ve insanları tıkayabilecek diller. Fakat bunlar sizi iyi kod yazmaya zorlayan dillerdir; Kötü uygulamalardan kaçmana izin vermediler. C, C ++, Java, Ruby, Python - ve bu programlama aşamasını daha da geliştiriyoruz, daha çok script benzeri, daha Yapısal Sorgu Diline ve PHP gibi dilleri gerçekten SQL'i çağırmak için kullandık. Size, arka planımdan geldiğimde, birçok yönden kendi kendime öğrendim ve öğrenmeme yardımcı olanları, çok iyi programlama uygulamaları ve buggy ile tanışmadığımdan emin olmak için tasarım ve süreçler etrafında çok iyi uygulamalar öğrendim. kodu.
Günümüzde programlama yöntemleri, örneğin Structured Query Language, SQL gibi şeyler çok güçlü ve basit bir sorgu dilidir. Fakat Weve onu bir programlama diline çevirdi ve SQL'in şimdiye kadar modern bir programlama dili olarak tasarlandığına gerçekten inanmıyorum, ama bunu yapmak için çarpıştık. Ve bu, iki bakış açısıyla düşündüğümüz zaman, kodlama bakış açısıyla ve DBA bakış açısıyla düşündüğümüz için bir sürü meseleyi ortaya çıkarır. Gelmesi ve sadece zayıf programlama teknikleri, kod yazarken tembel çaba, deneyim eksikliği, örneğin Google’da atlama ve bir şeyler bulma ve bir web sitesi bulma gibi SQL insanlarıyla sahip olduğum klasik evcil hayvan bakıcısı gibi şeyler için hatalar ortaya koyması çok kolay. bir örnek aldım ve mevcut kodu kopyalayıp yapıştırın. Ve sonra kötü bir kodlamayı, yanlış uygulamayı ve üretime sokmayı kopyalamak, çünkü onlara istedikleri sonuçları verir. Başka zorluklar yaşadınız, örneğin, bugünlerde hepsi buna acele ediyordu, yarışı sıfıra çağırıyoruz: çok ucuz ve hızlı olan her şeyi yapmaya çalışmak, daha düşük ücretli personel istihdam etmeyecek bir senaryomuz var. Ve bunu anlamsız bir şekilde kastetmiyorum, ama her olası iş için uzmanları işe almıyorduk. Bir zamanlar bilgisayarlarla ilgili bir şey roket bilimi idi; Patlayan ve çok gürültülü olan ya da uzaya giden şeylerle ilgiliydi ya da mühendisler, derece delikleri olan ve çılgınca şeyler yapmalarını engelleyen titiz eğitimler almış kalifiye erkekler ve kadınlardı.
Bu günlerde, uzun yıllar deneyime sahip olmayan pek çok halk, geliştirme ve tasarım ve veri tabanına giriyor, mutlaka aynı eğitim ve desteğe sahipti. Ve böylece sadece geleneksel amatör versus uzmanı senaryosuyla son buluyorsunuz. Ve ünlü bir çizgi var, aslında teklifi kim belirttiğini hatırlayamıyorum, sıra şöyle devam ediyor: “Pahalı bir iş yapmak için bir uzman işe almayı düşünüyorsanız, sorun yaratan birkaç amatör işe başlayana kadar bekleyin. temizleyin. ”SQL'in de bu sorunu var ve öğrenmesi çok kolay, kullanımı çok kolay. Ama bence mükemmel bir programlama dili değil. Her yerden bir seçme yıldızı yapmak ve PHP ve Ruby veya Python gibi daha rahat olduğunuz bir programlama diline çekmek ve veri manipülasyonunu yapmak için doğal olarak aşina olduğunuz bir programlama dilini kullanmak gibi şeyleri yapmak çok kolaydır. SQL'de daha karmaşık bir sorgu yapmak yerine. Bunu çok görüyoruz ve sonra insanlar veritabanının neden yavaş çalıştığını merak ediyorlar; bunun nedeni, bir milyon insanın, her yerden, seçkin bir yıldız yaptığı çevrimiçi bir bilet sistemi oluşturan bir bilet almaya çalıştığıdır.
Şimdi, bu gerçekten aşırı bir örnek, ama bunların hepsinden bir noktaya geliyorsunuz. Bu yüzden, eve gerçekten sadece yumruk atmak için, etrafta taşıdığım bir örnek var. Büyük bir matematik hayranıyım, kaos teorisini seviyorum, Mandelbrot kümelerini seviyorum. Sağ tarafta, kesinlikle aşina olduğum Mandelbrot setinin bir yorumu var. Sol tarafta, aslında bunu veren bir SQL parçası var. Şimdi, bunu bir ekrana ne zaman bir yere koysam, şunu duyuyorum: “Aman Tanrım, biri Mandelbrot serisini SQL ile işledi, ciddi misin? Bu çılgınca! ”Eh, bütün mesele, orada sadece özetlediklerimi göstermek ve bu evet, aslında, şimdi SQL'de hemen hemen her şeyi programlayabilirsiniz; çok ağır gelişmiş, güçlü, modern bir programlama dili. Başlangıçta bir sorgu dili iken, sadece veri toplamak için tasarlanmıştı. Bu yüzden şimdi çok karmaşık yapılar kurduk ve saklı yordamlar aldık, programlama metodolojisini bir dile uyguladık ve bu nedenle zayıf programlama uygulaması, deneyim eksikliği, kes ve yapıştır kodu, düşük ücretli personel için çok kolay yüksek ücretli personel, insanlar bildikleri gibi davranırlar, ancak işi öğrenmeleri gerekir.
Kod profilleme ve hata ayıklama olarak adlandırdığımız şeylerin tümü, programların çalışmasını durduran hatalar bulmak değil, sadece sistemi ve kötü yapılandırılmış kodu inciten hatalar. Şimdi bu ekrana baktığınızda ve bunun sadece sevimli olduğunu düşündüğünüzde ve “Vay, ne harika bir grafik, onu çalıştırmayı seviyorum” diyorsunuz. Ancak bunun bir iş mantığı üzerinde çalıştığını hayal edin. Oldukça zarif görünüyor, ancak matematiksel olarak grafiksel olarak oluşturulmuş bir kaos teorisini konuşuyor, ancak bazı iş mantıklarında potansiyel olarak ne kullanılabileceğini düşündüğünüzde, resmi çok hızlı bir şekilde elde edersiniz. Ve bunu gerçekten göstermek için - ve üzgünüm, renkler tersine çevrildi, yeşil bir ekran olması için siyah bir arka plan ve yeşil olması gerekiyordu, ama yine de bunu okuyabilirsiniz.
Gerçekten delirmiş olsaydınız ve ne olursa olsun herhangi bir deneyime sahip değilseniz ve farklı bir programlama geçmişinden geldiyse ve C ++ benzerlerini SQL'e uyguladıysam, daha önce amacımı açıklamak için potansiyel olarak yapabileceklerinize bir örnek verdim. IDERA'dan öğrenilen konuğumuza teslim ediyorum. Bu, C ++ gibi yazılmış ancak SQL'de kodlanmış bir sorgudur. Ve aslında yürütüyor, ancak yaklaşık üç ila beş dakikalık bir sürede yürütüyor. Ve görünüşte birden fazla veritabanından, birden fazla birleşmeden bir satır veri çeker.
Yine, tüm mesele şu ki, eğer doğru araçlara sahip değilseniz, bu şeyleri yakalamak için doğru platformlara ve ortamlara sahip değilseniz ve üretime girerlerse, o zaman her sisteme 100.000 kişi giriyor demektir. gün, saat veya dakika, çok yakında, büyük demirin erimeye başladığı ve kendisini gezegenin çekirdeğine gömmeye başladığı Çernobil deneyimini yaşarsınız, çünkü bu kod parçası asla üretime girmemelidir. Afedersiniz, sistemleriniz ve araçlarınız, test işlemi sırasında bile, UAT ve sistem entegrasyonu sırasında bile, bu kod parçasının kaldırılması ve vurgulanması, birinin kenara alınması ve “Bakın, bu gerçekten güzel bir kod, ancak bu yapılandırılmış sorguyu doğru bir şekilde oluşturmanıza yardımcı olması için bir DBA alabilmemize izin veriyor, çünkü açıkçası bu çok kötü.” Ve oradaki URL'ler, gidip bir bakabilirsiniz - Şimdiye kadar yazdığın en karmaşık SQL sorgusu. Çünkü inan bana, bu derleme yapar, çalışır. Ve eğer bunu kesip yapıştırarak veritabanını alay ederseniz, izlemesi gereken bir şeydir; veritabanını izlemek için araçlara sahipseniz, üç ila beş dakikalık bir süre içinde eritmeye çalışın, bir satırın ne olduğunu geri çağırın.
Dolayısıyla, özetlemek gerekirse, kodlama konusundaki bütün geçmişim bana insanlara silah verebileceğinizi ve eğer dikkatli olmazlarsa kendilerini ayağından vuracaklarını; İşin püf noktası, güvenlik mekanizmasının nerede olduğunu göstermektir. Doğru araçlar ve doğru yazılımla parmaklarınızın ucunda, kodlamayı yaptıktan sonra kodunuzu inceleyebilir, kodu profilleyerek sorunları bulabilir, performans sorunları olan istenmeyen istenmeyen hataları bulabilir ve daha önce de söylediğim gibi , bir zamanlar, yeşil bir ekrana bakarak yapabilirdi. Artık yapamazsın; yüz binlerce kod satırı var, konuşlandırılmış on binlerce uygulama var, bazı durumlarda milyonlarca veritabanı var ve süper insanlar bile bunu gerçekten elden yapamıyor. Kelimenin tam anlamıyla doğru yazılıma ve doğru araçlara parmaklarınızın ucunda ihtiyacınız var ve bu araçları kullanmak için ekibinize ihtiyaç duyuyorsunuz, bu sayede konuya gelmeden önce bu sorunları bulup çok hızlı bir şekilde çözebilirsiniz. Robin Bloor vurguladı, işler ya feci hale geldi ve işler patladı, ya da daha genel olarak, neden sadece işe yaramayacakları zaman moral ve eşyalarını yok etmeye, çok paraya, çok zaman ve çabaya mal olmaya başlıyorlar. Kaçması uzun zaman aldı.
Ve bunu akılda tutarak, konuğumuza teslim edeceğim ve bu sorunu nasıl çözdüklerini duymayı dört gözle bekliyorum. Ve özellikle demoyu almak üzere olduğunu düşünüyorum. Eric, geri döneceğim.
Eric Kavanagh: Tamam Bert, al onu.
Bert Scalzo: Tamam teşekkürler. IDERA'dan Bert Scalzo, veritabanı araçlarımızın ürün müdürü Im. Ve hata ayıklama hakkında konuşacağım. Bence Robin'in daha önce söylediği en önemli şeylerden biriydi - ve en doğru olanı, hata ayıklamanın zahmetli ve önemsiz olduğu ve veritabanına gittiğinizde büyüklük sırasını daha da zahmetli ve önemsiz hale getirdiğidir. önemli bir teklifti.
TAMAM. Tarihin programlanması ile başlamak istedim, çünkü çoğu zaman hata ayıklamayan insanları görüyorum, hata ayıklayıcı kullanmıyorlar, sadece kullandıkları dili kullanarak programlıyorlar ve çoğu zaman bana söyleyeceklerini söylüyorlar. bu hata ayıklayıcı şeyler yeni ve biz bunları kullanmaya başlamadık. ”Ve yaptığım şey şu, onlara zaman çizelgesi şemasını, bir tür tarih öncesi, yaşlılık, orta çağ, nerede olduğumuzu gösteriyorum. programlama dilleri terimleri. Ve 1951'den başlayarak derleme koduyla, Lisp ve FACT ve COBOL ile çok eski dillerimiz vardı. Sonra bir sonraki gruba, Pascals ve C'lere, sonra da bir sonraki gruba, C ++ 'lara gireriz ve bu soru işaretinin nerede olduğuna bakalım - bu soru işareti yaklaşık 1978'den belki de 1980'e doğru. Bu aralığın içinde bir yerde bizim için mevcut olan hata ayıklayıcılar ve “Hey, bir hata ayıklayıcı kullanmıyorum, bu yeni şeylerden birisine neden olamıyorum” demek için. Öyleyse, 1950’lerde geri döndüğünüzde programlamaya başlamış olmalısınız. Bu iddia ile uzağa.
Şimdi bu grafikte komik olan diğer şey Dez, Grace Hopper hakkında bir yorum yaptı, aslında Grace'i tanıdım, bu yüzden komik. Sonra güldüğüm diğer şey teletiplerden bahsetti ve orada oturuyorum, “Adam, kartlardan teletiplere gittiğimizde üretkenlikteki en büyük sıçramaydı.” ve burada daha önce hiç kimsenin duymadığı SNOBOL de dahil olmak üzere tüm dilleri programladım, bu bir CDC, Control Data Corporation oldu, sanırım bu sektör için biraz yaşlandım.
Dez Blanchfield: Söyleyecektim, bizi orada çok yaşlandırdın.
Bert Scalzo: Evet, sana söylüyorum, Büyükbaba Simpson gibi hissediyorum. Bu yüzden hata ayıklamaya bakıyorum ve hata ayıklamanın farklı yolları var. Geleneksel olarak bir hata ayıklayıcısına girmenin ve kodları atmanın geleneksel olduğunu düşündüğümüz şeylerden bahsediyor olabilirsiniz. Ancak, insanlar kodlarını da gösterecek; ifadeleri kodunuza koyduğunuz ve belki de bir çıktı dosyası, bir izleme dosyası ya da başka bir şey ürettiğiniz ve bu nedenle kodunuzu belirttiğiniz yer. Bunu hata ayıklama olarak, biraz daha zor, bunu yapmanın bir yolu olarak sayardım, ama sayılır. Ama aynı zamanda, ünlü ifadeye ulaştık: izlersiniz ve insanlar aslında ifadeler ekler ve aslında bir aracı gördüm - ve bunun bir veritabanı aracı - nerede bir hata ayıklayıcı kullanmayı bilmiyorsanız, bir düğmeye basar ve kodunuzdaki ifadeler sizin için ve sonra bittiğinde başka bir düğmeye basarsın ve onları çıkarır. Çünkü birçok insan hata ayıklıyor.
Ve hata ayıklamanın nedeni iki yönlüdür: her şeyden önce, kodumuzu etkisiz hale getiren şeyleri bulmalıyız. Başka bir deyişle, bu genellikle mantıksal bir hata olduğu anlamına gelir veya bir iş gereksinimini kaçırdık, ancak sorun ne, kodun etkili olmadığı; yapmasını beklediğimiz şeyi yapmaz. Gittiğimiz ve hata ayıklama yaptığımız diğer zaman, bunun verimlilik için ve bu mantıklı bir hata olabilirdi, ama ne olduğu, doğru olanı yaptım, yeterince hızlı bir şekilde geri gelmedi. Şimdi, bu noktayı anlıyorum çünkü profilciler muhtemelen ikinci senaryo için daha iyi ve hem hata ayıklayıcılar hem de profilciler hakkında konuşacaklardı. Ayrıca, bu uzaktan hata ayıklama kavramı var; bu önemlidir çünkü kişisel bilgisayarınızda oturuyorsanız ve bir hata ayıklayıcı kullanıyorsanız, kodun veritabanında yürütüldüğü bir veritabanına isabet ederseniz, aslında uzaktan hata ayıklama adı verilen şeyi yapıyorsunuzdur. Farkında olmayabilirsin, ama olan bu. Ve sonra, bu hata ayıklayıcıların kırılma noktalarına, noktalara dikkat etmelerine, adım atmalarına ve adım atmalarına ve diğer bazı ortak şeylere sahip olmalarının çok yaygın olduğu, bunları anlık olarak ekranda göstereceğim.
Şimdi, profil oluşturma: profillemeyi birkaç farklı yolla yapabilirsiniz. Bazı insanlar iş yükünün her şeyi yakaladığı ve yeniden yakaladığını, profil olarak sayıldığını söyleyecektir. Örneklemem bittiğinde deneyimlerim daha iyi oldu. Her bir ifadeyi yakalamak için bir neden yoktur, çünkü bazı ifadeler umursamadığınız kadar hızlı çalışabilir, gerçekten görmeye çalıştığınız şey, peki, bunlar tekrar tekrar ortaya çıkmaya devam ediyor, çünkü çok uzun sürüyorlar. . Bu yüzden, bazen profil oluşturma, her şeyi yürütmek yerine örnekleme anlamına gelebilir. Ve tipik olarak, bir IDE geliştirme ortamının içinde görsel olabilen, size çeşitli kod satırlarının performansının histogramı gibi verebileceği, ancak yine de kullanabileceği bir tür çıktı elde edeceksiniz. bir izleme dosyası oluşturuyor olabilir.
Profilciler ilk kez 1979'da ortaya çıktılar. Yani, onlar da uzun zamandır buralardalar. Kaynak tüketimini veya performans sorunlarını bulmak için harika, başka bir deyişle bu verimlilik olayı. Genel olarak konuşursak, her ikisi de aynı anda yapan hata ayıklayıcılarla çalışmış olmama rağmen, hata ayıklayıcıdan ayrı ve farklı. Ve profilciler bence iki aracın daha ilginç olduğunu düşünürken, yeterince insanın hata ayıkladığını hissetmezsem, o zaman kesinlikle yeterli insan profili olmaz, çünkü on hata ayıklayıcısından biri profil çıkarır gibi görünüyor. Ve bu utanç verici çünkü profil oluşturma gerçekten çok büyük bir fark yaratabilir. Şimdi, daha önce konuştuğumuz gibi, veritabanı dilleri SQL'e sahiptiniz - ve yuvarlak pimi burada kare deliğe soktunuz ve bir programlama dili - ve Oracle olmaya zorladınız.Bu PL / SQL - yordamsal SQL dili SQL - ve SQL Server, Transact-SQL, SQL-99, SQL / PSM - sanırım Prosedür Saklanan Modülü için. Postgres, başka bir isim, DB2, başka bir isim, Informix verir, ama asıl nokta, herkesin 3GL tipi yapıları zorladığını; Başka bir deyişle, FOR döngülerinde, değişken bildirimlerinde ve SQL'e yabancı olan diğer tüm öğeler artık bu dillerde SQL'in bir parçasıdır. Ve böylece, bir Visual Basic programında olduğu gibi bir PL / SQL veya bir Transact-SQL'de hata ayıklayabilmeniz gerekir.
Şimdi, veritabanı nesneleri, bu önemlidir çünkü insanlar, “Peki, bir veritabanında hata ayıklamak zorunda kalacağım şeyler” diyeceklerdir. Ve cevap, eğer veritabanında kod olarak saklayabileceğiniz ne varsa - yani eğer SQL veya PL / SQL - ve Im veritabanındaki nesneleri saklıyorum, muhtemelen saklı bir prosedür veya saklanmış bir fonksiyondur. Ama aynı zamanda tetikler: tetikleyici bir çeşit saklı yordam gibidir, ancak bir çeşit olaya ateş açar. Şimdi, tetikleyicilerindeki bazı insanlar bir satır kod koyacak ve saklı bir prosedürü arayacaklar, böylece tüm saklı kodlarını ve prosedürlerini saklayabilecekler, ama aynı kavram: hala tetikleyici her şeyi başlatan şey olabilir. Ve sonra Oracle olarak, eğer bir kütüphane gibi olacak bir paket adı verilen bir şeye sahipler. 50 ya da 100 saklı yordamı paket olarak adlandırılan bir gruba koyarsınız, böylece bir kütüphane gibi. Yani, hata ayıklayıcısını eski şekilde saptar; Bu aslında aslında girip tüm bu hata ayıklama ifadelerini sizin için kodunuza sokacak bir araçtır. Böylece, hata ayıklama bloğunu gördüğünüz her yerde, kaldırmayın, otomatik hata ayıklayıcı başlar ve izler, bunların hepsi bir takım tarafından sıkışmış. Ve bunun dışındaki satırlar, kodun azınlığı, yani manuel olmayan hata ayıklama yöntemi.
Ve bunu ortaya çıkarmamın nedeni, eğer bunu elle yapmaya çalışıyorsanız, aslında tüm bu ifadeleri koyduğunuzdan daha fazla hata ayıklama kodu yazacaksınız. Öyleyse, bu işe yarayabilirken ve hiç olmamasından daha iyi olmasına rağmen, bu hata ayıklamak için çok zor bir yol, özellikle de, bu şeyin çalışması 10 saat sürdüğü ve üçüncü sırada olduğu bir sorunun nerede olduğu için? Etkileşimli bir hata ayıklama oturumu yapıyor olsaydım, satırın 3-5 dakikasında bunu biliyor olurdum - hey, burada bir sorun var, istifa edebilirim. Ancak bununla birlikte çalışmasını beklemeliyim, sonuna kadar devam ettim ve daha sonra içinde tüm bu ifadeleri içeren bir izleme dosyasına bakmalı ve samanlıktaki iğneyi bulmaya çalışmalıyım. Yine, bu hiç olmamasından iyidir, ancak çalışmanın en iyi yolu olmazdı. Şimdi, bu dosya önceki slayttan gelmiş gibi görünüyordu; Başka bir deyişle, programı çalıştırdım ve bu izleme dosyasında bir sürü ifadeye sahibim ve bunun üzerinden sifon alıp bulmam gerekeni bulabilirim veya olmayabilir. Yani, yine, çalışmak istediğinin bu olduğundan emin değilim.
Şimdi, etkileşimli hata ayıklayıcılar - programlar yazmak için Visual Studio ya da Eclipse gibi bir şey kullandıysanız, hata ayıklayıcıları kullandınız ve onları diğer dillerinizle kullandınız - bunları burada veritabanınızla kullanmayı düşünmediniz. Ve orada DB Artisan ve Rapid SQL'lerimiz gibi araçlar var, buradaki burada bir hata ayıklayıcısına sahip olan Rapid SQL ve sol tarafta görebileceğiniz gibi, “kopyaları kontrol et” adlı saklı bir prosedür var. Temel olarak, sadece gidip bakacak ve aynı film başlığına sahip masada birden fazla satır olup olmadığına bakacağım. Yani, veritabanı filmler içindir. Ve sağ tarafta görebiliyorsunuz, ilk üçte, kaynak kodumu ortada buldum, saat değişkenlerim ve çağrı yığını tepsilerim denilen şeye sahibim ve sonra en altta bazı çıktılar aldım. Ve burada önemli olan, eğer ilk kırmızı oka bakarsanız, bir değişkenin üzerinde fareyi oynatırsam, o anda o değişkende hangi değerin kodda ilerlerken Im olduğunu görebiliyorum. Ve bu gerçekten yararlı, ve sonra bir kerede kod boyunca bir adım atabilirim, yürütmek zorunda değilim, bir satır diyebilirim, ne olduğuna bakmama izin ver, başka bir satıra adım at, ne olduğunu görmeme izin ver ve Bunu veritabanında yapıyorum. Bilgisayarımda Rapid SQL üzerinde otursam ve veritabanım bulutta kalsa da, hala uzaktan kontrol etmeyi ve onu görmeyi ve buradan kontrol etmeyi ve diğer dillerde yaptığım gibi hata ayıklamayı hala yapabiliyorum.
Şimdi, bir sonraki oka - sağa işaret eden küçük oku görebiliyorsunuz, o DBMS çıktısına doğru, imlecimin şu an olduğu yer orası - yani başka bir deyişle, adım attığım yer şu anki yerim. Yani, “Tekrar adım” dersem, bir sonraki satıra geçeceğim. Şimdi bunun hemen altında kırmızı noktayı göreceksin. Eh, bu bir kırılma noktası, “Hey, bu çizgilerin üzerinden adım atmak istemiyorum” diyor. Eğer her şeyin üstünden atlamak ve o kırmızı noktanın üzerine gelmek istersem, run düğmesine basabilirim ve buradan da buraya ayarlanan herhangi bir kesme noktası varsa, son veya bir kesme noktası için, o zaman durur ve tekrar adım atmama izin verir. Ve bunların hepsinin önemli ve güçlü olmasının nedeni, bunların hepsini yaptığım zaman, ortada ve hatta dipte olanları - ama en önemlisi ortası - değişecekleri ve değişkenlerimden değerleri görebildiğimdir. çağrı yığın izlememi görüyorsun, biliyorsun, ve böylece tüm bu bilgiler orada kodun içinde ilerliyorum olarak görüntüleniyor, bu yüzden gerçekte ne olup bittiğini ve kodun gerçekten yürütme zamanında çalıştığını anlayabiliyorum. . Ve tipik olarak, eğer bir problem varsa veya onu yakalayacak kadar iyiysem bir problem bulabilirim.
Tamam, şimdi bir profilci hakkında konuşacağım ve bu durumda, bu bir hata ayıklayıcıdan görebileceğim bir profilci. Unutma ki bazen ayrılar, bazen birlikte olabilirler? Bu durumda ve yine Rapid SQL'de Im ve sol tarafta satır numaralarının yanında bir kenar boşluğu görebiliyorum. Ve bu, her kod satırını yürütmek için harcadığı saniye veya mikrosaniye sayısıdır ve açıkça görebiliyorum ki, zamanımın hepsi bir tablodan her şeyi seçtiğim bir FOR döngüsünde harcanıyor. Ve böylece, bu FOR döngüsünün içinde meydana gelenler muhtemelen bakmam gereken bir şeydir ve eğer daha iyisini yapabilirsem, temettü ödeyecek. 0,90 veya 0,86 gibi bir çizgi üzerinde çalışarak herhangi bir gelişme elde etmeyeceğim; Orada harcanan fazla zaman yok. Şimdi, bu durumda, ve yine, Rapid SQL’de Im, hata ayıklama ile birbirine karışan profillemeyi nasıl yapabileceğimi görüyorsunuz. Şimdi, güzel olan Rapid SQL de başka bir şekilde yapmanıza izin veriyor. Hızlı SQL, “Ne biliyor musun? Hata ayıklayıcısında olmak istemiyorum, sadece bunu çalıştırmak istiyorum ve sonra aynı grafiksel veya görsel olarak aynı bilgilere bakmak istiyorum. ”
Artık hata ayıklayıcımda bulunmadığımı ve programın çalıştığını görüyorsunuz ve yürütme tamamlandıktan sonra, bana bir şeyler anlatmam için çizelgeler veriyor, böylece en çok pastanın toplanmasına benzeyen bir ifade aldığımı görebiliyorum çizelge ve eğer bakarsam, bu ızgarayı tabana doğru bakarım, satır 23, tekrar FOR döngüsüne gelir: hes çoğu zaman alır, aslında koyu kırmızı tüm pasta grafiğini yukarı çeker. Ve böylece, bu profil oluşturma için başka bir yoldur. Bizim aracımızda bu “Kod Analisti” diyoruz. Ama temelde sadece bir hata ayıklayıcıdan ayrılmış bir profil oluşturucu. Bazı insanlar ilk, bazı insanlar ikinci yapmaktan hoşlanır.
Neden hata ayıklama ve profil çıkarma yapıyoruz? Bunun nedeni, dünyanın en büyük kodunu yazmak ve bir ücret artışı almak istememiz - bu bizim sebebimiz olabilir, ama bu gerçekten sizin için bir neden değil - işe doğru bir şeyler yapacağınıza, programınızın etkili olacağına söz verdiniz. Hata ayıklayıcısını bunun için kullanacaksınız. Ayrıca işletme son kullanıcıları; Çok sabırlı değiller: tuşuna basmadan önce bile sonuç istiyorlar. Akıllarını okumak ve her şeyi anında yapmak gerekiyordu. Başka bir deyişle, verimli olmalı. Ve böylece, profilleyiciyi bunun için kullanırdık. Şimdi, bu araçlar olmadan, ok ve yay ile iş takımındaki bu adamın ... ... hedefe ateş ettiğini ve gözlerinin bağlı olduğuna inandığına inanıyorum. Çünkü bir programın sadece statik koda bakarak nasıl yürütüldüğünü ve yürütme işleminde en çok zaman geçirdiği yerin hangi satırda olduğunu, yine sadece statik koda bakarak nasıl bulacağınızı nasıl öğreneceksiniz? Bir kod incelemesi bunlardan bazılarını ortaya çıkarabilir veya açmayabilir, ancak bir kod incelemesinin hepsini bulacağının garantisi yoktur. Bir hata ayıklayıcı ve profil oluşturucu kullanarak bu hataların tümünü bulabilmelisiniz.
Tamam, burada gerçekten hızlı bir demo yapacağım. Ürünü itme niyetim değil, sadece bir hata ayıklayıcısının nasıl göründüğünü göstermek istiyorum, çünkü insanlar çoğu zaman “Bunlardan birini daha önce hiç görmedim” diyecekler. hareket halindeyken benziyor mu? Öyleyse, burada benim ekranımda DB Artisan ürünümüzü çalıştırıyorum; Orada da bir hata ayıklayıcımız var. DB Artisan, DBA'lar için daha çok kastedilmiştir, Rapid SQL, geliştiriciler için daha fazladır, ancak DB Artisan'ı kullanan geliştiriciler gördüm ve ben de Rapid kullanan DBA'lar gördüm. Yani, ürün üzerinde yakalanmayın. Ve burada, hata ayıklama yapma seçeneğim var, ancak hata ayıklamayı başlatmadan önce, bu kodu çıkaracağım, böylece çalıştırmadan önce kodun nasıl göründüğünü görebilirsiniz. Öyleyse, ekran görüntüsündeki kodun aynısı, bu benim kopyalarımı kontrol ediyorum. Ve bunu hata ayıklamak istiyorum, bu yüzden hata ayıklamaya basıyorum. Ve şimdi, bir dakika sürüyor ve siz de “Peki, neden biraz zaman alıyor?” Diyorsunuz. Uzaktan hata ayıklamayı hatırlayın: Hata ayıklama aslında bilgisayarımda değil, veritabanı sunucumda oluyor. Bu yüzden oraya gidip orada bir oturum oluşturmak, uzaktan hata ayıklama bir şey oluşturmak, oturumu uzaktan hata ayıklama oturumuna bağlamak ve bir iletişim kanalı kurmak zorunda kaldı.
Yani, şimdi, benim okum var, üstte, üstte, birinci satırda, kodda olduğum yer. Ve eğer üçüncü adıma basarsam, içine bir adım attığımda, o okun hareket ettiğini göreceksiniz ve basmaya devam edersem, hareket etmeye devam ettiğini göreceksiniz. Şimdi, bu FOR döngüsünün sonuna kadar gitmek istersem, çünkü sorunun nerede olduğunu biliyorum, bir kesme noktası ayarlayabilirim. Bunu ayarladığımı sanıyordum. Ateş, benim ekran yakalama anahtarlarımdan biri hata ayıklayıcı olarak aynı anahtarla eşleştirildi, bu karışıklığa neden olan şey vardı. Tamam, o zaman sadece manuel olarak bir kesme noktası belirledim, o yüzden şimdi bir adım, adım, adım, adım olana kadar adım atmak yerine aslında “Sadece devam et ve bu şeyi çalıştır” diyebilirim ve duracaktır. Beni kırılma noktasının olduğu yere indirdi, bu yüzden şimdi bu döngüyü çalıştırma konusuna girdim, tüm değişkenlerimin neye ayarlanmış olduğunu görebiliyorum, bu sürpriz değil, çünkü hepsini başlattım. sıfır. Ve şimdi, bu döngüye girebilir ve bu döngünün içinde olup bitene bakmaya başlayabilirim.
Bu yüzden, şimdi kiralamalarımdan bir miktar seçecek ve o adamın üzerine fare ile bakabilirim, bak, iki, iki tane birden büyük, bu yüzden muhtemelen bu kodun bir sonraki parçasını yapacak. Başka bir deyişle, bir şey buldu. Ben sadece devam edip koşmasına izin vereceğim. Burada her şeyden geçmek istemiyorum; Size göstermek istediğim şey, bir hata ayıklayıcı yapıldığında, normal bir program gibi bitiyor. Kesme noktasını ayarlamıştım, yani kaçtığımı söylediğimde, bir sonraki kesme noktasına geri döndü. Sonuna kadar çalışmasına izin veriyorum, çünkü görmenizi istediğim şey, bir hata ayıklayıcının programın davranışını değiştirmemesidir: Çalışması bittiğinde, hata ayıklayıcı içinde çalıştırmamış olsaydım, aynı sonuçları almalıyım.
Ve bununla birlikte, demoyu askıya alacağım ve geri döneceğim çünkü sorular ve cevaplar için zamanımız olduğundan emin olmak istiyoruz. Ve böylece, sorular ve cevaplar için açacağım.
Eric Kavanagh: Tamam, Robin, belki senden bir soru ve sonra Dez'den bir çift?
Robin Bloor: Evet, elbette, bunu büyüleyici buluyorum. Böyle şeylerle çalıştım ama veritabanında böyle bir şeyle hiç çalışmadım. İnsanların profili ne için kullandığı hakkında bir fikir verebilir misin? Çünkü onlar, bakıyorlar mı - çünkü olduklarını sanıyorum - performans sorunlarına bakıyorlar, bir veritabanının ne zaman zaman alacağı ve bir kodun ne zaman zaman alacağı arasında ayrım yapmanıza yardımcı olacak mı?
Bert Scalzo: Biliyor musun, bu harika bir soru. Diyelim ki Visual Basic'te çalışıyorum ve Visual Basic'ümün içinde bir Transact-SQL veya PL / SQL arayacağım. PL / SQL'i yapmama izin verin, çünkü Oracle her zaman Microsoft araçlarıyla iyi oynamıyor. Visual Basic kodumu profillendiriyor olabilirim ve oradaki profil “Hey, bu saklı yordamı aradım ve çok uzun sürdü” diyebilir. Ancak daha sonra saklı yordama girebilir ve saklanan üzerinde bir veritabanı profili yapabilirim Prosedürü söyleyin ve “Tamam, burada bulunan 100 ifadeden, soruna neden olan beşine dikkat edin.” Böylece, birden çok profilleyici kullanmanız gereken bir etiket ekibi yapmanız gerekebilir.
Fikir, performans sorununu veritabanınızda gördüğünüzde, bir veritabanı profili samanlıkta bulunan iğneyi bulmanıza yardımcı olabilir. Size profil oluşturma ile ilgili başka bir şey söyleyeyim: milyon kez çağrılan bir kod kodunuz varsa, ancak milyonlarca kez bir mikrosaniyeyi alır, ancak milyonlarca kez çağrılır, profilerin göstereceği şeyi Bu şey, bu kadar zaman birimi için koştu. Bu yüzden kod oldukça verimli olabilirken, “Ooh, bu çağrıyı bu kod parçasına çok sık yapıyorlardı. Belki de bir rekor işlediğimiz her seferinde değil, sadece sık sık çağırmalıyız ”. Ve böylece aslında çok sık çağrılan ve aslında performans sorunu olan verimli kodun nerede olduğunu bulabilirsiniz.
Robin Bloor: Evet, bu harika. Bunu asla yapmadım. Tabii ki, veritabanı problemleri yaşadığımda, bir şekilde ya da bir başkası ya veritabanı ile uğraşıyor ya da kodla uğraşıyor gibiydim; İkisiyle de aynı anda asla başa çıkamam. Ama orada, yine yapmadım - Ben aslında hiçbir zaman saklı yordamlar yaptığımız uygulamaların yapımında yer almadım, bu yüzden sanırım beni aslında çılgına çeviren sorunlara rastlamadım. veritabanı ve bir program. Fakat öyleyse, hepsini yapın - Cevapların evet olacağını farz ediyorum, ancak bu, bir şekilde ya da başka bir şey kırılmış bir şeyi düzeltmeye çalışırken ya da belki yeni bir uygulamayı bir araya getirmeye çalışırken, bir geliştirme ekibi faaliyetinin parçası. Ancak bunların hepsi çevrede beklediğim diğer bileşenlerle uyumlu mu? Bunu tüm test paketlerimle ve yapabileceğim diğer şeylerle ve proje yönetimi malzemelerimle birlikte kesebilmemi bekleyebilir miyim?
Bert Scalzo: Evet, programlama ya da geliştirme çalışmalarınızı yapmak için herhangi bir yapılandırılmış sürecin bir parçası olabilir. Ve komik, geçen hafta bir web uygulaması yapan bir müşterim vardı ve veritabanları tarihsel olarak küçüktü ve çok iyi programcılar olmadıkları gerçeği onlara zarar vermedi. Veritabanları yıllar geçtikçe büyüdü ve şimdi bir web sayfasında 20 saniye sürüyor, “Giriş yap ve bana görmem için biraz veri ver” derken, ekran gerçekten açıldığında ve performans sorunu. Sorunun kendi Java'sında veya diğer yerlerde olmadığını biliyorlardı. Ancak binlerce saklı yordamları vardı ve bu web sayfasının neden 20 saniye sürdüğünü bulmak için saklı yordamları profillemeye başlamak zorunda kaldılar? Ve aslında onların seçtikleri ifadelerden birinde Kartezyen birliği olduğunu gördük ve bilmiyorduk.
Robin Bloor: Vay.
Bert Scalzo: Ama birileri bana bir keresinde şöyle dedi: “Peki, nasıl Kartezyen katılabilirdi ve bunu bilmiyor?” Ve bu ses gerçekten korkunç; bazen SQL ile pek rahat olmayan bir programcı bana Kartezyen katılımı vermek gibi bir şey yapar, ama sonra sadece ilk kaydı geri verir, bu yüzden bir şey aldığımı biliyorum ve yalnızca birincisine ihtiyacım var. Ve böylece, milyarlarca kayıt geri getirdiklerini ya da milyarlarca kayıt aradıklarını fark etmiyorlar, çünkü ilgilendiklerini kaydettiler.
Robin Bloor: Vay canına, bilirim, bunlar ne denir - yani, Dez'in devam ettiği şey, tam olarak ne olması gerektiği kadar yetenekli olmayan insanlar açısından, bilirsin. Bir programcıysanız, herhangi bir komutu vermenin ne anlama geldiğini bilmelisiniz. Demek istediğim, gerçekten, bu kadar aptallık düzeyi için mazeret yok. Ayrıca, bir şekilde ya da başka bir şekilde, sadece bu konuda dil bilen bir dil olduğunuzu farz ediyorum, çünkü bunların hepsi veritabanı tarafına odaklanıyor. Bu konuda haklı mıyım? Kodlama tarafında ne kullanıyorsanız kullanın, aynısı mı?
Bert Scalzo: Kesinlikle, bunu Fortran veya C veya C ++ ile yapabilirsiniz. Aslında, bazı Unix'lerde bile betik dilleri için yapabilirsiniz; aslında aynı araçları sağlarlar. Ve sonra mazeret etmeden söylediğin şey için bir saniye geri dönmek istiyorum. Programcılara bir mola vereceğim, çünkü programcıları otobüse atmaktan hoşlanmıyorum. Ancak sorun gerçekten akademik ortam çünkü programcı olmayı öğrenmeye başladığınızda, her seferinde rekor düşünmeyi öğretiyorsunuz. Size küme düşüncesini öğretmediniz ve Yapısal Sorgu Dili veya SQL'in kümelerle çalıştığı şey bu; Bu yüzden sendika, kesişen ve eksi operatörümüz var. Ve bazen setler halinde hiç düşünmeyen, istifa eden, bir kerede rekor işlemeyi bırakan ve setlerle çalışan biri için çok zor.
Robin Bloor: Evet, bu konuda seninleyim. Yani, şimdi anlıyorum, bu bir eğitim sorunu; Bunun tamamen bir eğitim sorunu olduğunu düşünüyorum, programcıların usule göre düşünmeleri doğal olduğunu düşünüyorum. Ve SQL işlemsel değil, bildirimsel değildir. Aslında sadece “İstediğim bu ve nasıl yaptığınız umrumda değil” diyorsunuz. Oysa programlama dilleri ile sık sık kollarınız kıvrılır ve ilmek yaparken sayıları yönetme bile- sinin önemsizliğine girersiniz. Hasta elime -
Bert Scalzo: Hayır. Tamam, devam et.
Evet, bir profilerin yakalamada iyi olacağı başka bir örnek daha getirdiğini söyleyecektim, bir seferde bu rekor işleme devam ediyordu. Bazen, her seferinde bir kayıt mantığında iyi olan bir programcı, SQL programının nasıl yapıldığını çözemez. Pekala, diyelim ki iki FOR döngüsü yapıyor ve temelde bir katılım yapıyor, ancak müşteri tarafında yapıyor. Yani, bir birleşim ile aynı etkiyi yapan hes, ancak bunu kendi kendine yapan hes ve bir profil bunu yakalayacaktır, çünkü birleştirme işleminin sizin için yapmasına izin vermekten daha fazlasını elle yapmak için daha fazla zaman harcarsınız.
Robin Bloor: Evet, bu felaket olur. Yani, sadece etrafta dolanıp duruyordun. Thrashings her zaman kötü.
Neyse, hasta Dez'e geçer; Eminim ki bazı ilginç sorular var.
Dez Blanchfield: Teşekkür ederim evet. Size otobüsün altındaki programcıları atmamak için katılacağım. Demek istediğim, hayatımda yıllarca kendimi kodlayıcı olmakla geçirdim, her seviyede, bildiğiniz gibi, Unix makinesinin komut satırında oturuyor ve hatta bazı durumlarda, bir donanım platformundan diğerine farklı Unix portları. Ve orada yaşadığımız zorlukları hayal edebilirsiniz. Ama gerçek şu ki, dünyadaki her kodlayıcı ve kodlayıcı için hapisten çıkma kartı olan heres. Bir roket bilimi, kelimenin tam anlamıyla, her zaman, her zaman gerçekten sıkı yazmak bir roket bilimidir. Ve Dennis Ritchie ve Brian Kernahan gibi insanların ünlü hikayeleri bağımsız olarak bir parça kod üzerinde çalışıyor ve daha sonra bir kahvede sohbet koduna dönüştüler ve tam olarak aynı programda, tam olarak aynı programda yazdıklarını belirlediler. aynı yol. Ve bunu C'de yaptılar. Fakat bu saf programlama düzeyi çok nadiren var.
Gerçek şu ki, günlük olarak, günde sadece 24 saat, haftada yedi gün, ve sadece işleri halletmek zorundayız. Ve böylece, sadece geleneksel programcılar, DBA'lar ve kodlayıcılar, senaryolar ve sysadmin ve ağ yöneticileri ve güvenlik personeli ve bugünlerde vatandaş veri tarafına giden her şey söz konusu olduğunda; duyuyoruz, herkes sadece işini yapmaya çalışıyor. Ve sanırım bu olayın en iyi paketi, demonuzu çok sevdim ve bize bir süre önce orada bıraktığınız paketi sevdim, bir dakika önce, Robin ile bunun belirli bir özelliği olduğu gerçeği hakkında konuştuk - belki de çok fazla bir niş - ancak kod, SQL ve veritabanlarını sabitleme kadar geçerli olduğu geniş bir alan. Ama onu bir kabuk betiğine sokabileceğinizi ve bazı sorunları bulabileceğinizi söylediğin için çok heyecanlıydım, çünkü bugünün ve yaşın her zaman en düşük maliyetle çalıştığını biliyorsunuz.
Bir yerde 6 dolarlık bir gömlek alabilmenizin sebebi, birinin aslında 6 dolarlık bir gömlek almak için çevrimiçi olarak üretim yapmak ve göndermek ve lojistik olarak teslim etmek ve satmak ve perakende satış yapmak ve çevrimiçi ödeme almak için yeterince ucuz bir sistem kurmasıdır. Ve bu, kodları mükemmel bir şekilde yazmak için insanlara yılda 400.000 dolar ödenmesini sağladıysanız olmaz; sadece tüm gelişimi. Yani, bu nokta, sanırım Id'nin bize biraz daha fazla bilgi vermeniz için gerçekten sevdiği sorulardan biri, şu anda gördüğünüz insanların bir türünü kodlamak ve incelemek için bu tür araçların dağıtımını yapan şeylerin genişliği ve erişimi. performans sorunları için? Başlangıçta, tarihsel olarak, nereden geliyorlar? Onlar büyük mühendislik evleri miydi? Ve sonra, ileriye doğru, durum şu ki, işi bitirmek için işleri kimin yaptığını bildikleri kodlayıcıları denemek ve yardım etmek için daha fazla şirketin bu aracı veya bu araçları uyguladıklarını düşünmekte haklı mıyım? ve kapıdan çıkar? Bazen hapisten çıkma kartına ihtiyacımız var mı? Tarihsel olarak daha fazla mühendislik odağımız ve gelişimimiz olduğunu düşünmekte haklı mıyım? Şimdi, Robin’in söylediği gibi akademik yaklaşım ve şimdi kendi kendini öğreten ya da kes ve yapıştır kodu, ya da sadece bir şeyler inşa etmek, daha az alıyordu? Ve bu, şu anda ürünü alan insanlarla uyuşuyor mu?
Bert Scalzo: Evet kesinlikle. Ve size çok özel bir örnek vereceğim: sadece işin yapılmasını istiyoruz, çünkü iş adamları mükemmellik istemiyor. Bilgisayarlı bir satranç oyunu gibi bir şey: satranç oyunu mükemmel cevap aramıyor; makul bir sürede yeterince iyi bir cevap arar, bu şekilde programlayacağız. Ama şimdi bulduklarım, çoğu insan birim testlerinin bir parçası olarak bir profilci istediklerini söylemek yerine - ki bu nasıl yapardım, çünkü onu zaman kaybı olarak görmüyorum - olan şu ki, şu anda yapılan şey daha sonra, bazen, eğer şanslılarsa, entegrasyon testi veya stres testi sırasında. Ancak, çoğu zaman bir şeylerin üretime girdiği bir tırmanışın parçası, bir süre koştu, hatta belki de yıllarca koştu ve şimdi de iyi sonuç vermiyor ve şimdi de iyi bir şekilde görünüyor. Ve bu şimdi daha yaygın bir senaryo gibi görünüyor.
Dez Blanchfield: Evet ve bence “teknik borç” terimi muhtemelen aşina olduğunuzdan çok daha fazlası. Robin'i biliyorum ve kesinlikle öyle. Bugünlerde özellikle geliştirmeye ve sistem geliştirmeye yönelik çevik yaklaşımlarda, bana göre, teknik borç kavramı çok gerçek bir şey ve bunu aslında projelerde hesaba katıyoruz. Demek istediğim, Media Lens ve diğerleri gibi günlük olarak kodlamanın gerçekleştiği kendi projelerimizi ve Bloor Grubu genelinde çeşitli şeyleri yaptık. Ve ne zaman bir şey inşa ediyor olsaydık, bir neye bakarız, ona bakarım ve şu anda bunu düzeltmenin bana neye mal olacağı konusunda her zaman bakarım, tam tersi kutuya alabilir miyim ve oraya çıkar ve sonra bu şeylerin çözülüp çözülmeyeceğini izle ve gör. Ve daha sonra geri dönüp düzeltmek zorunda olacağımı bildiğim bu teknik borcu devralır.
Demek istediğim, bunu son yedi gün içinde yaptım: Birkaç araç ve senaryo yazdım, birkaç parça Python dili yazdım ve onu Mongo'ya yerleştirerek güzel ve temiz ve güvenli olmasını sağladım. ama sadece yapmam gereken sorguyu alıyor, bu fonksiyonun çalışması gerektiğini, daha büyük bulmacayı elde etmem gerektiğini biliyor; gerçek acımın olduğu yer burası. Ve böylece bu teknik borcu doğuruyorsunuz ve bence bu şimdi sadece bir durum değil, bunun şu an gelişmekte olan DNA'nın bir parçası olduğunu düşünüyorum. Sadece insanlar - titizlikle değil - sadece teknik borcun normal bir operadi cinsi sorun olduğunu kabul ediyorlar ve sadece bunu yapmak zorundalar. Teknik borcunuzu aldığınız yer. Ve bence gösteride bize gösterdiklerinizle ilgili en güzel şey, kelimenin tam anlamıyla bir profilin ne kadar sürdüğünü izleyebilmeniz ve izleyebilmenizdi. Ve bu muhtemelen benim en sevdiğim şeylerden biri. Yani, aslında profil oluşturma araçları geliştirdim - kodumuzu çalıştırmak ve döngülerin nerede olduğunu görmek için Sed ve Lex ve Orc'ta araçlar oluşturduk, bunun gibi araçlar mevcut olmadan önce - ve kendi kodunuzu bulmak ve gözden geçirmek için kod oluşturdunuz , kendi kodunuzu gözden geçirmek zorunda kalmamakta çok başarılı oluyorsunuz. Ama şimdi durum böyle değil. Bunu akılda tutarak, bunu diğerlerinden daha fazla alan belirli bir pazar segmenti var mı? Bir kütle gibi görmek -
Bert Scalzo: Oh evet, anladım - senin için bir benzetme çizeceğim ve programcı olmayanların her zaman yaptığını göstereceğim. Çünkü bir hata ayıklayıcıya ve profil sınıfına veya oturuma ders veriyorum, hastalara soruyorum: “Tamam, buradaki kaç kişi Microsoft Word'e giriyor ve kasıtlı olarak asla yazım denetleyicisini kullanmıyor mu?” hepimiz biliyoruz ki İngilizce hatalar yapabiliriz ve böylece herkes yazım denetleyicisini kullanır. Ben de dedim ki: “IDE'nizde Visual Basic gibi yazarken, hata ayıklayıcısını kullanmıyorken nasılsınız? Aynı şey, bir yazım denetleyicisi gibi. ”
Dez Blanchfield: Evet, aslında, bu harika bir benzetme. Gerçekten düşünmemiştim, itiraf etmeliyim ki, kullandığım birkaç araçla benzer bir şey yaptığımı. Aslında, Eclipse ile en sevdiğim ODF kodları kesip yapıştırıyor ve hemen vurgulayan şeyleri aramaya başlıyor ve bazı sınıf çağrısında bir yazım hatası yaptığımı fark ediyor. Ve, ancak şimdi bunun gibi bir araçla ilginç olması, geri dönüp daha sonra bakmanın aksine gerçek zamanlı olarak yapabilirsiniz, bu da önceden anlaşılması güzel bir şey. Ama evet, bu sadece bir kelime işlemciye koymanın harika bir benzetmesi, ilginç bir uyandırma çağrısı olmasına neden olur, sadece bazı yazım hataları veya dilbilgisi hatası yaptığınızı fark edin, değil mi?
Bert Scalzo: Kesinlikle.
Dez Blanchfield: Yani, sanırım artık daha fazla bir tepki görüyor musunuz, demek istediğim, benden son bir soru, katılımcılar için belki de soru-cevap kısmına atmadan önce. Bunu yapma yaklaşımı etrafında bir tür öneride bulunacaksanız - bunun retorik olduğunu farz ediyorum - gelişmeden önce erken gelip bunu geliştiriyormuş gibi uygulamış olmanızın durumu var mı? Ya da esas olarak inşa edersiniz, hareket edersiniz, sonra bir şeyler inşa edersiniz ve daha sonra profil yaparsınız? Erken gelme durumundan şüpheliyim ve kodlarınızın açık olduğundan emin olun. Yoksa konuşlandırmalarının bu bölümünü dikkate almaları gereken bir durum mu?
Bert Scalzo: İdeal olarak, bunu baştan yaparlardı, ancak herkes işlerin bitmesi için acele, kalabalık bir dünya olduğu için, daha fazla CPU ve bellek ekleyerek çözemedikleri bir performans sorununa girinceye kadar bunu yapmaya meyilli değiller. sanal bir makineye.
Dez Blanchfield: Evet. Yani, hızlıca yapabilirsem aslında ilginç bir şeyden bahsettiniz? Bundan daha önce bahsetmiştin, bu herhangi bir yerden çalıştırılabilir ve arka uçtaki veritabanıyla konuşabilir. Bu, şimdi bahsettiğimiz, şirket içi / şirket dışı buluttan bahseden bimodal konseptiyle, günün sonunda, arka uçtan konuşup bakabiliyorsa, şeylerin bakışı ile rahattır. Kod gerçekten umrumda değil, değil mi?
Bert Scalzo: Kesinlikle, evet, bunu bulutta çalıştırabilirsiniz.
Dez Blanchfield: Mükemmel, çünkü yeni cesur dünyamızın nereye gittiğini düşünüyorum. Öyleyse Eric. Şimdi size geri döneceğim ve bir kaç sorunun burada olduğunu göreceğim ve katılımcıların bir saat geçmesine rağmen hala katılımcıların bizimle kalmasını istiyorum.
Eric Kavanagh: Evet, dışarıda birkaç kişi var, Sadece hızlıca bir yorum yapalım: Bert, bence yazım denetimini kullanmak için verdiğin benzetmenin metaforun mükemmel olduğunu düşünüyorum. Açıkçası bir bloga yakışır, açıkçası, çünkü ne yaptığınız ve ne kadar değerli olduğu konusunu çerçevelemek için iyi bir yoldur. Düzenli olarak, doğru mu? Bahse girerim bunu attığın zaman başını sallarsın, değil mi?
Bert Scalzo: Kesinlikle, çünkü onlara söylediklerim “Neden belgelerim üzerinde yazım denetimi yapıyorum? Aptal yazım hatalarından utanmak istemiyorum. ”Eh, aptal kodlama hatalarından utanmak istemiyorlar!
Eric Kavanagh: Sağ. Evet kesinlikle. Millet, burada bir saat beş dakika geçirdik, zamanınız ve ilginiz için hepinize çok teşekkürler. Tüm bu web sohbetlerini arşivliyoruz, istediğiniz zaman geri gelmekten ve kontrol etmekten çekinmiyoruz. Bu bağlantıları bulmak için en iyi yer muhtemelen techopedia.com'dur, bu yüzden bu listeyi buraya ekleyin.
Ve bununla, size veda edeceksiniz millet. Bir kez daha, büyük iş, Bert, IDERA'dan gelen arkadaşlarımıza teşekkürler. Gelecek sefer seninle konuş, gelecek hafta seninle konuş, aslında. Kendine iyi bak! Güle güle.