Techopedia Staff, 15 Mart 2017
Paket Servisi: Sunucu Eric Kavanagh Dr. Robin Bloor, Dez Blanchfield ve IDERA'dan Bert Scalzo ile veritabanı hata ayıklama ve profil oluşturma konularını ele aldı.
Şu anda giriş yapmadınız. Lütfen videoyu görmek için giriş yapın veya üye olun.
Eric Kavanagh: Pekala, bayanlar ve baylar, Çarşamba günü saat 4:00 Doğu zamanı ve elbette bu demek.
Robin Bloor: Seni duyamıyorum, Eric.
Eric Kavanagh: Günler önce oradaydım, bu yüzden yalnız değilsin. Ama bugünkü konu gerçekten ilginç şeyler. Şirketinizdeki arka planda olduğundan emin olmak istediğiniz bir şeydir, bunu yapan kişi siz değilseniz, bu durumda düzgün bir şekilde yaptığınızdan emin olmak istersiniz. Çünkü hata ayıklamadan bahsediyoruz. Kimse hataları sevmez, yazılım çalışmayı bıraktığında kimse sevmez - insanlar üzülür, kullanıcılar düşmanca olur. Bu iyi değil. Bu yüzden, "Hızlı Yanıt: Veritabanı Hata Ayıklama ve Kurtarmaya Profil Oluşturma" hakkında konuşacağız.
Sizinkiyle ilgili bir nokta var, Twitter'da beni vurun, elbette @eric_kavanagh.
Bu yıl sıcak. Ve ne olursa olsun hata ayıklama sıcak olacak. Bu sorunlardan ne kadar iyi olursa olsun, her zaman sorun olacak, bu yüzden bu sorunları hızlı bir şekilde çözebileceğiniz yere nasıl gidersiniz? İdeal olarak, çok fazla yanlış gitmeyen, ancak eski deyişle, “Kazalar ailelerin en iyisinde meydana gelir” gibi harika programcılarınız, harika ortamlarınız var. Aynı şey organizasyonlar için de geçerlidir. Yani, bu şeyler oluyor, olacak, soru onunla başa çıkmak ve bu problemleri çözmek için çözümünüz ne olacak?
Robin Bloor'dan, sonra kendi Dez Blanchfield'ımızdan aşağıdan ve elbette IDERA'dan iyi arkadaşımız Bert Scalzo'dan haber alacağız. Ve aslında, Robin Bloor'un anahtarlarını teslim edeceğim, götürün. Zemin sizindir.
Robin Bloor: Tamam. Bu, enteresan bir konu. Dez muhtemelen hata ayıklama ile ilgili gerçek teknikler ve savaş hikayeleri hakkında devam edeceğinden, sadece arka plan tartışması yapacağımı düşündüm, böylece neler olup bittiğine dair tam bir resim elde etmeliyiz. Bunu uzun bir süre yaptım ve eskiden kodlayıcıydım, bu yüzden ve bu sunumla neredeyse açık kaynak fikri hakkında lirik ağlamaya başlamak için cazip davrandım ama bunu başka birine bırakacağımı düşündüm.
İşte ünlü hataların bir listesi ve bunların çoğu herkesin en iyi listesine giriyor, temelde, son ikisi hariç en az 100 milyon dolara mal oluyor. Birincisi Mars İklim Orbiter'iydi, uzayda kayboldu ve bunun nedeni insanların metrik birimleri (inç) ayak ve inç ile karıştırdığı bir kodlama problemiydi. Ariane Five Flight 501, takılan bir motor ile fırlatıldığında roketi çalıştırması gereken bilgisayarlar arasında bir uyumsuzluk vardı. Birden fazla bilgisayar arızası, patlayan roket, manşet haberleri. 1982'deki Sovyet gaz boru hattı, gezegenin tarihindeki en büyük patlama olduğu söyleniyor; Bunun olup olmadığından emin değilim. Ruslar bazı otomatik kontrol yazılımlarını çaldılar ve CIA bunu yapacaklarını ve hatalar koyacaklarını fark etti ve Sovyetler bunu test etmeden uyguladılar. Yani, bir boru hattını havaya uçurdu, eğlenceli olduğunu düşündüm.
Morris solucanı, aniden herkesin etrafına dolanan korkunç bir solucan haline gelen bir kodlama denemesiydi - görünüşe göre 100 milyon dolar değerinde hasara neden oldu; bu elbette bir tahmin. Intel, 1993 yılında Pentium çipinde matematik eğitimi olan ve 100 milyon doların üzerinde bir maliyete sahip olduğu bir matematik çipi ile ünlü bir hata yaptı. Apple'ın Haritalar programı, Apple'ın şimdiye kadar yapmış olduğu her şeyin en kötü ve en yıkıcı lansmanıdır. Kullanmayı deneyen insanlar, yani, 101 kişi boyunca sürüyorlardı ve Apple Haritasının San Francisco Körfezi'nin ortasında olduklarını söylediğini keşfetti. Böylece insanlar Apple Maps uygulamasına iLost olarak başvurmaya başladı. 1990'daki en uzun kesintimiz - böyle bir şeyin maliyeti açısından sadece ilginç - AT&T yaklaşık dokuz saat sürdü ve uzun mesafeli aramalarda 60 milyon dolara mal oldu.
Bir İngiliz sigorta şirketindeydim ve veritabanında, veritabanının yeni bir sürümünü uyguladılar ve verileri silmeye başladılar. Ve bunu son derece iyi hatırlıyorum, çünkü daha sonra bu nedenle bir tür veritabanı seçimine katılmaya çağrıldım. Ve veritabanının yeni bir sürümünü almış olmaları çok ilginçti ve veritabanının yeni sürümleri için tüm testleri geçtikleri için yaptıkları testler vardı. Verileri silmek için gerçekten belirsiz bir yol buldu.
Her neyse, işte bu. Empedans uyumsuzluğu ve verilen SQL hakkında konuşacağımı düşündüm. İlişkisel veritabanlarının verileri tablolarda depolaması ilginçtir ve kodlayıcılar, tablolarla gerçekten çok iyi eşleşmeyen nesne yapılarındaki verileri değiştirme eğilimindedir. Ve bu nedenle, empedans uyumsuzluğu olarak adlandırılan şeyi alırsınız ve birileri bununla bir şekilde uğraşmak zorundadır. Ancak gerçekte ne olur, çünkü bir model, kodlayıcının modeli ve veritabanı başka bir model özellikle hizalanmamıştır. Endüstri birlikte çalışan bir şeyler inşa etseydi, olmayacağını düşündüğüm hatalar alıyorsunuz, ki bu çok komik. Yani, temelde, kodlayıcıların tarafında, hiyerarşileri aldığınızda türler olabilir, kümeler oluşturabilir, zayıf API yeteneği olabilir, sadece veritabanı ile etkileşim açısından bir şeyleri dışarı atan birçok şey olabilir. Ama benim için en önemli şey, gerçekten ilginç; kodlayıcılar ve veritabanı birbirleriyle çalışacak şekilde bir çeşit empedans olan bu SQL bariyerine sahip olduğunuzu her zaman hayrete düşürdü. Bu nedenle, SQL veri tanıma özelliğine sahiptir ve iyi seçim, projelendirme ve katılma için DML'ye sahiptir. Veritabanından veri alma konusunda çok fazla yetenek atabilirsiniz. Ama bir şeyler yapmak için çok az matematik dili var. Biraz bundan ve buna sahip ve çok az zamana dayalı şeyler var. Ve bu nedenle, SQL verileri almak için bir kusurdur. Yani, veritabanı adamları veritabanında yaşamak için saklı yordamlar inşa etti ve orada yaşayan saklı yordamların nedeni gerçekten bir programa veri ileri geri atmak istemiyordu.
Bazı işlevler son derece veriye özgü olduğundan, sadece referans bütünlüğü ve basamaklı silmeler ve bunun gibi şeyler değildi, veritabanı, veritabanına aniden tüm işlevsellikleri hallediyordu, bu da elbette ki bir uygulamanın işlevselliği kodlayıcı ve veritabanının kendisi arasında bölünebilir. Ve bu, bazı işlevleri yerine getirme işini gerçekten oldukça zor ve dolayısıyla daha fazla hataya eğilimli hale getirdi. Yani, bu veritabanı oyununun bir tarafı, çünkü çok fazla uygulamaya sahip olduğunuz, ilişkisel veritabanlarında yer aldığım anlamına gelir, işlenen saklı yordamlarda oturan çok fazla kod var uygulamalardaki koddan ayrı olarak. Ve olması gereken çok garip bir şey gibi görünüyor, çeşitli şeyler yapmakta oldukça akıllı olması gerekiyordu.
Performans hataları genellikle hata olarak kabul edildiğinden veritabanı performansı hakkında da konuşacağımı düşündüm, ancak temelde CPU'da, bellekte, diskte, ağda bir darboğazınız olabilir ve kilitleme nedeniyle performans sorunları yaşayabilirsiniz . Fikir, kodlayıcının performans hakkında gerçekten endişelenmesi gerekmediği ve veritabanının gerçekte oldukça iyi performans göstereceği yönündedir. Kodlayıcının bilmesi gerekmeyecek şekilde tasarlanması gerekiyordu. Ancak, kötü veritabanı tasarımı olsun, kötü program tasarımı olsun, iş yükü karıştırmada eşzamanlılık elde edersiniz, bu da performans sorunlarına yol açabilir. Yük dengelemesine, kapasite planlamasına, veri büyümesine - bir veritabanının durmasına veya yavaşlamasına neden olabilirsiniz. Bu ilginç bir şey, veritabanları neredeyse dolduğunda yavaşlarlar. Ve veri katmanları çoğaltma ve çoğaltma ihtiyacı ve yedekleme ve kurtarma yapma ihtiyacı açısından sorun olabilir. Her 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 - ve çoğu zaman bunun hata ayıklamadaki tüm durumlar gibi olduğunu keşfedeceğim şimdiye kadar deneyimlediğiniz, gördüğünüz ilk şey bir karmaşadır. Ve dağınıklığın nasıl ortaya çıktığını anlamaya çalışmak zorundasınız. Ve genellikle bir veritabanı sorununa baktığınızda, baktığınız tek şey bozuk verilerdir ve “Bu nasıl oldu?” Diye düşünüyorsunuz.
Her neyse, muhtemelen çıkacağımdan daha fazla bilgelik sözü söyleyecek olan Dez'e geçeceğim. Sana topu nasıl geçireceğimi bilmiyorum, Dez.
Eric Kavanagh: Ben geçeceğim, dayanacağım, bekle.
Otomatik ses: Katılımcı hatları kapatıldı.
Eric Kavanagh: Pekala, bir saniye bekle, Dez'e topu vereyim.
Dez Blanchfield: Teşekkürler, Eric. Evet, Dr. Robin Bloor, sen gerçekten çok haklısın: bu bir konu, cinasini affedersen ömür boyu süren bir hata, özür dilerim kendime yardım edemedim. Umarım orada ilk ekranımı, üstteki yazı tipi boyutu sorunu için özür dilerim. Böcek konusu, benim durumumda birçok durumda gün boyu süren bir derstir. Bu kadar geniş ve geniş bir konu, bu yüzden iki önemli alana odaklanacağım, özellikle bir hata olarak düşündüğümüz kavram, ancak bir programlama sorunu. Bence bu günlerde bir hata tanıtan, uzun süren hatalar olabilir, ancak genellikle entegre geliştirme ortamları tarafından alınır. Ancak çoğu zaman bu bir profil oluşturma örneğidir ve bir hata olması gereken fonksiyonların kodunu yazmak mümkündür. Yani, burada başlığım kayıyor, bunun çok yüksek çözünürlüklü A3'te bir kopyası vardı, ama maalesef bir ev hareketinde yok edildi. Ancak bu, 1945 dolaylarında, ABD'deki Harvard Üniversitesi'nde bazı halkların Mark II adlı bir makinenin ikinci yapısının olduğu bir programlama sayfasında el yazısı notu. Ortak bir dilde bazı sorunları ayıklıyorlardı, ancak bir hata bulmaya çalışıyorlardı ve bir donanım ve sözde yazılım sorunundan biraz farklı bir şey ortaya çıktı.
Kentsel mit, 9 Eylül 1945'te Harvard Üniversitesi'ndeki bir ekibin bir makineyi parçalarına ayırdığı, “yetmiş röle” olarak adlandırdıkları bir şeyle karşılaştıklarıdır - o günlerde programlama fiziksel anlamda yapıldı, kodu yaraladın bir makinenin etrafında ve makineyi etkili bir şekilde programladınız - ve bu röle numarasını yetmiş bulmuşlar ve bununla ilgili bir sorun vardı ve gerçekte "böcek" teriminin ortaya çıktığı için tam anlamıyla bir güve - sözde orada bir yerden bir yere giden bir parça bakır tel arasına sıkışmış bir güve. Ve hikaye, bu slayt başlığı olarak efsanevi Grace Hopper'ın başlık slaydım için, “ilk gerçek böcek bulgusu” alıntı unquote.
Ancak Robin ilk slaytında daha önce vurguladığı gibi, bir böcek kavramı, insanların yama gibi kavramlar hesapladığını hayal edebildiğimiz kadar ileri gider. “Yama” terimi, bir zımba kartındaki bir deliğin üzerine bantlanmış gerçek bir bant parçasından geldi. Ancak tüm mesele, “hata ayıklama” teriminin fiziksel bir makinede bir hata bulma kavramından çıkmasıdır. Ve o zamandan beri, bu terminolojiyi, derlenmeyen bir programdaki kodlama sorunları kadar değil, iyi çalışmayan bir program olarak sorunlarla başa çıkmaya çalışmak için kullandık. Ve özellikle de hiçbir yere gitmeyen, hiç bitmeyen döngüler gibi şeyler bulmak profilli değildir.
Ama aynı zamanda bir senaryomuz var ve biraz daha ayrıntıya girmeden önce birkaç komik slayt koyacağımı düşündüm. İşte web üzerinde XKCD adı verilen klasik çizgi film ve karikatürist dünya hakkında oldukça komik manzaralara sahip. Ve bu, “Küçük Bobby Masaları” adlı bir çocuk hakkında ve sözde ailesi bu genç çocuğu Robert 'olarak adlandırdı); DROP TABLE Öğrenciler; - ve buna denir ve bir çeşit “Merhaba, bu oğlunuzun okulunda bilgisayar sorunu var” diyor ve ebeveyn “Ah canım, bir şey kırdı mı?” Diyor ve öğretmen, “Şey, bir şekilde ”diye sordu ve öğretmen“ gerçekten oğluna Robert adını verdin mi? ”diye soruyor; DROP TABLOSU Öğrenciler; -? ”Ve ebeveyn der ki, “ Evet, ona küçük Bobby Tablolar diyoruz. ”Her neyse, artık yılın öğrenci kayıtlarını kaybettiklerini söylemeye devam ediyorlar, umarım mutlu olursun. Ve yanıt, “Eh, veritabanı girişlerinizi temizlemeli ve sterilize etmelisiniz.” Ve bunu birçok kez koddaki şeyleri bulmakta yaşadığımız bazı problemlerden bahsetmek için kullanıyorum, genellikle kod verilere bakmıyor de.
Bir başka komik olan, bunun gerçek olup olmadığını bilmiyorum - bunun bir parodi olduğundan şüpheleniyorum - ama yine komik kemiğime de dokunuyor. Birisi arabalarının önündeki plakayı, hız kameralarında veri tabanlarının düşmesine neden olan benzer bir ifadeyle değiştirir ve böylece araçların plakalarını yakalar. Ve her zaman, herhangi bir programcının gerçek bir motorlu araç tarafından kodlarının bir vuruşunu ve çalışmasını beklediğinden şüphe duyduğumu ifade ediyorum, ama asla bunu hafife almayın - kızgın bir geek'in gücü.
(Kahkaha)
Ama bu beni kilit noktama götürüyor, sanırım ve bu bir zamanlar hata kodu ve profil kodunu sadece ölümlüler olarak çıkarabiliriz. Ama o zamanın geçtiğine ve benim deneyimlerime göre, ilk önce - ve bu beni çok yaşlandıracağından eminim; Robin bana bunun için eğlenceli bir şeyler söyleyebilirsin - ama tarihsel olarak 14 yaşındayken şehrin sonuna doğru dolaşırken ve “Data Com” adlı bir veri merkezinin kapısını çalmaya başladım. Zelanda ve geç otobüsü eve, her gün yaklaşık 25 km gidip, yazıcılara kağıt ve teyp sürücülerine bant koyarak ve sadece genel bir yönetici olarak okulda harçlık kazanıp kazanamayacağımı soruyor. Ve merakla bana bir iş verdiler. Ama zamanla, kendimi kadroya sokmayı ve programcıları bulmayı başardım ve kodlamayı sevdiğimi fark ettim ve günün sonunda hala kod olan senaryoları ve toplu işleri yürütme sürecinden geçtim. Mini programlara benzeyen komut dosyaları ve toplu işler yazmanız ve ardından 3270 terminal yazma kodunda el ile oturmanın tüm sürecinden geçmeniz gerekir.
Aslında, ilk deneyimim, 132 sütunlu fiziksel yazıcı olan bir teletype terminalinde oldu. Esasen, içinde kayan kağıt bulunan çok eski bir daktilo gibi düşünün, çünkü CRT tüpleri yoktu. Kod hatalarını ayıklamak çok önemsiz bir konuydu, bu yüzden tüm kodunuzu elle yazma ve sonra daktilo gibi davranma, gizlice girmemek için elinizden gelenin en iyisini yapma eğilimindesiniz, çünkü anlatmak son derece sinir bozucu belirli bir satıra gidip sonra satırı yazıp tekrar yazmanız için bir satır editörü. Ama bir zamanlar kod böyle yazdık ve bu şekilde hata ayıkladık ve çok, çok iyi olduk. Aslında, bizi çok iyi programlama tekniklerine sahip olmaya zorladı, çünkü bunu düzeltmek gerçek bir güçlüktü. Ancak yolculuk daha sonra geçti - ve hepimiz buna aşinayız - dünyamdaki 3270 terminal deneyiminden, ekranda bir şeyler görebileceğiniz Dijital Ekipman VT220'ye gitti, ama yine aynı şeyi yapıyordunuz kağıt kaset üzerinde sadece bir CRT'de basılı formatta çalıştınız, ancak daha kolay bir şekilde silebilirdiniz ve bu “dit dit dit dit” sesiniz yoktu.
Ve sonra biliyorsunuz, Wyse terminalleri - Wyse 150 gibi, muhtemelen şimdiye kadar bir bilgisayara en sevdiğim arayüz - ve daha sonra PC ve sonra Mac ve daha sonra bu günlerde web tabanlı modern GUI'ler ve kimlikler. Ve bununla bir dizi program, tek bir programcı ve PILOT ve Logo ve Lisp ve Fortran ve Pascal ve insanları kandırdıracak dillerdeki programlama. Ancak bunlar sizi iyi kod yazmaya zorlayan dillerdir; kötü uygulamalardan kurtulmanıza izin vermediler. C, C ++, Java, Ruby, Python - ve bu programlama aşamasına ilerledikçe, daha fazla komut dosyası benzeri oluyoruz, Yapısal Sorgu Dili'ne ve aslında SQL'i çağırmak için kullanılan PHP gibi dillere yaklaşıyoruz. Size arka planımdan geldiğimi söylüyorum, birçok yönden kendi kendime öğretildim ve öğrenmeme yardımcı olanlar, bana çok iyi programlama uygulamaları ve tasarım ve süreçler etrafında çok iyi uygulamalar öğretti. buggy kodunu tanıtmak.
Bu günlerde programlama yöntemleri, örneğin, Yapısal Sorgu Dili, SQL gibi şeyler, çok güçlü, basit bir sorgu dilidir. Ancak bunu bir programlama diline dönüştürdük ve SQL'in şimdiye kadar modern bir programlama dili olarak tasarlandığına gerçekten inanmıyorum, ancak bunu yapmak için eğlendik. Ve bu bir takım sorunları ortaya çıkarır, çünkü iki bakış açısından düşündüğümüzde: kodlama açısından ve DBA bakış açısından. Gelmek ve sadece kötü programlama teknikleri, kod yazmada tembel çabalar, deneyim eksikliği, klasik evcil hayvan peeve gibi şeyler için böcek tanıtmak çok kolay, örneğin Google'da atlayan ve bir şey arayan ve bir web sitesi bulmak olan SQL insanlarıyla bir örnek aldım ve mevcut kodun bir kopyasını yapıştırın. Ve sonra kötü bir kodlama, yanlış uygulama ve onu üretime sokmak, çünkü sadece istedikleri sonuçları vermek oluyor. Başka zorluklarınız var, örneğin, bugünlerde hepimiz buna doğru koşuyoruz, yarışı sıfıra çağırıyoruz: her şeyi çok ucuz ve çok hızlı yapmaya çalışıyoruz, daha düşük istihdam etmediğimiz bir senaryomuz var ücretli personel. Bunu küfürlü bir şekilde kastetmiyorum, ama olası her iş için uzman işe almıyoruz. Bir zamanlar bilgisayarlarla ilgili her şey roket bilimi idi; patlama yapan ve çok gürültülü olan ya da uzaya giden ya da mühendisler, derece yapan ve çılgın şeyler yapmasını engelleyen titiz eğitimler alan çok nitelikli erkekler ve kadınlardı.
Günümüzde, uzun yıllara dayanan tecrübesi olmayan, aynı eğitim veya desteğe sahip olmayan birçok geliştirme ve tasarım ve veri tabanına giriyor. Ve böylece sadece geleneksel amatörlere karşı uzman bir senaryo ile bitiyorsunuz. Ve ünlü bir çizgi var, aslında alıntıyı kimin oluşturduğunu hatırlayamıyorum, çizgi şöyle devam ediyor: “Eğer bir iş yapmak için bir uzman kiralamanın pahalı olduğunu düşünüyorsanız, bir sorun yaratan birkaç amatör kiralayana kadar bekleyin ve temizlemek zorundayız. ”Ve böylece SQL'in bu sorunu var ve öğrenmesi çok, çok kolay, kullanımı çok kolay. Ama bence mükemmel bir programlama dili değil. Nereden olursa olsun bir yıldız seçmek ve bunları PHP ve Ruby veya Python gibi daha rahat bir programlama diline çekmek ve yerel olarak aşina olduğunuz programlama dilini kullanmak gibi şeyleri yapmak çok kolaydır. SQL'de daha karmaşık bir sorgu yapmak yerine veri manipülasyonu. Bunu çok görüyoruz ve insanlar veritabanının neden yavaş çalıştığını merak ediyor; çünkü bir milyon insan, herhangi bir yerden bir yıldız seçtiği bir çevrimiçi bilet sistemi üzerinden bir bilet almaya çalışıyor.
Şimdi, bu gerçekten aşırı bir örnek, ama tüm bunlardan anladınız. Yani, bu noktayı gerçekten gerçekten yumruklamak için, çok fazla taşıdığım bir örnek. Ben matematiğin büyük bir hayranıyım, kaos teorisini seviyorum, Mandelbrot setlerini seviyorum. Sağ tarafta Mandelbrot setinin bir yorumu var, ki eminim hepimiz aşinayız. Ve sol tarafta bunu yapan bir SQL parçası var. Şimdi bunu her yerde bir ekrana koyduğumda şunu duyuyorum: “Tanrım, birisi Mandelbrot serisini SQL ile işledi, ciddi misin? Bu delilik! ”Bunun asıl amacı, orada ana hatlarıyla anlattığım şeyi göstermek ve evet, aslında SQL'de hemen hemen her şeyi programlayabilirsiniz; çok gelişmiş, güçlü, modern bir programlama dilidir. Başlangıçta bir sorgu dili olduğunda, sadece veri almak için tasarlanmıştır. Yani, şimdi çok karmaşık yapılarımız var ve saklı prosedürlerimiz var, bir dile uygulanan programlama metodolojimiz var ve bu nedenle zayıf programlama uygulaması, deneyim eksikliği, kes ve yapıştır kodu, düşük ücretli personel, yüksek ücretli personel olmaya çalışıyor, insanlar biliyormuş gibi davranıyorlar, ama işte öğrenmeleri gerekiyor.
Kod profili oluşturma ve hata ayıklama olarak adlandırdığımız bir dizi şey, bu programların çalışmasını durduran hataları değil, sadece sistemi ve kötü yapılandırılmış kodu inciten hataları buluyor. Şimdi bu ekrana baktığınızda ve bunun sadece sevimli olduğunu düşünüyorsunuz ve “Vay be, ne harika bir grafik, bunu çalıştırmayı çok isterim.” Ama bir iş mantığı üzerinde koştuğunuzu düşünün. . Oldukça düzgün görünüyor, ancak matematiksel grafik olarak oluşturulmuş bir kaos teorisinden bahsediyor, ancak bazı iş mantığında potansiyel olarak ne için 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 döndü, siyah bir arka plan ve yeşil bir metin yeşil bir ekran olması gerekiyordu, ama yine de okuyabilirsiniz.
Gittim ve gerçekten çılgın olsaydınız ve hiçbir deneyiminiz yoksa ve farklı bir programlama geçmişinden geldiyse potansiyel olarak neler yapabileceğinize bir örnek gördüm ve daha önce noktamı gerçekten göstermek için C ++ 'ın SQL' e benzerlerini uyguladım. IDERA'dan öğrenilmiş konuğumuza teslim ediyorum. Bu, C ++ gibi yazılmış yapılandırılmış bir sorgudur, ancak SQL'de kodlanmıştır. Ve aslında yürütür, ama yaklaşık üç ila beş dakikalık bir süre boyunca yürütür. Görünüşte bir veri hattını birden çok veritabanından, birden çok birleştirmeden geri çeker.
Yine, tüm mesele şu ki, doğru araçlara sahip değilseniz, bunları yakalamak için doğru platformlara ve ortamlara sahip değilseniz ve üretime girerler ve sonra 100.000 insanınız vardır. her gün, saat ya da dakika bir sisteme çarparsanız, çok yakında büyük demirin erimeye ve kendini gezegenin çekirdeğine gömmeye başladığı bir Çernobil deneyimi yaşarsınız, çünkü bu kod parçası asla üretilmemelidir. Sistemleriniz ve araçlarınız, özür dilerim, test süreci boyunca, hatta UAT ve sistem entegrasyonu aracılığıyla bile, bu kod parçası alınmalı ve vurgulanmalı ve birisi bir kenara getirilmeli ve “Bakın, bu gerçekten güzel bir kod, ama bu yapılandırılmış sorguyu doğru bir şekilde oluşturmanıza yardımcı olacak bir DBA alalım, çünkü açıkçası, bu sadece kötü.” Ve URL orada, gidip bir göz atabilirsiniz - buna yazdığınız en karmaşık SQL sorgusu. Çünkü inan bana, bu gerçekten derleniyor, koşuyor. Ve bunu kesip yapıştırırsanız ve sadece veritabanını alay ederseniz, izlenmesi oldukça kolaydır; Veritabanını izlemek için araçlarınız varsa, sadece bir ila beş dakikalık bir süre içinde eritmeyi deneyin, bir metin satırının ne olduğunu geri çağırın.
Özetlemek gerekirse, bunu akılda tutarak, kodlamadaki tüm geçmişim bana insanlara silah verebileceğinizi öğretti ve eğer dikkatli olmazlarsa kendilerini ayağa vururlar; işin sırrı, onlara güvenlik mekanizmasının nerede olduğunu göstermektir. Doğru araçları ve doğru yazılımı parmaklarınızın ucunda, kodlamayı yaptıktan sonra, kodunuzu inceleyebilir, kodu profilleyerek sorunları bulabilirsiniz, performans sorunları olan istenmeyen istenmeyen hataları etkili bir şekilde bulabilirsiniz ve dediğim gibi daha önce, bir zamanlar, yeşil bir ekrana bakarak yapabilirdiniz. Artık yapamazsın; yüz binlerce kod satırı vardır, on binlerce uygulama konuşlandırılmıştır, bazı durumlarda milyonlarca veritabanı vardır ve hatta süper insanlar bunu artık elle yapamazlar. Kelimenin tam anlamıyla doğru yazılıma ve doğru araçlara parmaklarınızın ucunda ihtiyacınız var ve ekibin bu araçları kullanması gerekiyor, böylece bu sorunları bulabilir ve noktaya gelmeden önce çok, çok hızlı bir şekilde çözebilirsiniz. Dr. Robin Bloor vurguladı, işler felaket oldu ve işler patladı ya da daha yaygın olarak, sadece bir sürü dolara ve çok fazla zaman ve çabaya mal olmaya ve moralleri ve şeyleri yok etmeye başlıyorlar. koşmak için uzun bir süre.
Bunu göz önünde bulundurarak misafirimize teslim edeceğim ve bu sorunu nasıl çözdüklerini duymak için sabırsızlanıyorum. Özellikle demoyu almak üzereyim. Eric, geri döneceğim.
Eric Kavanagh: Tamam Bert, götürün onu.
Bert Scalzo: Tamam, teşekkür ederim. Bert Scalzo burada IDERA'dan, veritabanı araçlarımızın ürün yöneticisiyim. Ve ben hata ayıklama hakkında konuşacağım. Sanırım Robin'in daha önce söylediği en önemli şeylerden biri - ve çok doğru, hata ayıklamanın zahmetli ve önemsiz olduğu ve veritabanı hata ayıklamaya gittiğinizde, daha da zahmetli ve önemsiz bir büyüklük sırası - yani, önemli bir teklifti.
TAMAM. Programlama geçmişi ile başlamak istedim, çünkü çoğu zaman hata ayıklamayan insanları görüyorum, hata ayıklayıcı kullanmıyorlar, sadece hangi dili kullanıyorlarsa programlıyorlar ve çoğu zaman bana söyleyecekler, “Eh, bu hata ayıklayıcı şeyler yeni ve henüz bunları kullanmaya başlamadık.” Ve bu yüzden onlara şu zaman çizelgesini, bir tür ön tarih, yaşlılık, orta çağ, nazik diyelim ki programlama dilleri açısından neredeydik. Ve 1951'de montaj kodu ile Lisp ve FACT ve COBOL ile başlayan çok eski dillerimiz vardı. Sonra bir sonraki gruba geçiyoruz, Pascals ve Cs ve bir sonraki gruba, C ++ s, ve bu soru işaretinin nerede olduğuna bakıyoruz - bu soru işareti yaklaşık 1978 ile belki 1980 arasındadır. hata ayıklayıcıları kullanabiliriz ve böylece, “Hey, bir hata ayıklayıcı kullanmıyorum, çünkü bu yeni şeylerden biri” diyerek, o zaman 1950'lerde programlamaya başlamış olmalısınız. bu iddiadan kurtulmanın tek yolu.
Şimdi bu grafikte komik olan bir diğer şey de Dez'in Grace Hopper hakkında yorum yaptığı, aslında Grace'i biliyordum, bu yüzden komik. Ve sonra güldüğüm bir diğer şey de teletiplerden bahsetti ve ben orada oturuyorum, “Adamım, kartlardan teletiplere gittiğimizde, verimlilikte şimdiye kadarki en büyük sıçramaydı, bu şimdiye kadarki en büyük sıçramaydı. “Bu yüzden, daha önce kimsenin duymadığı SNOBOL dahil olmak üzere buradaki tüm dillerde programladım, bu bir CDC, Control Data Corporation'dı, bu yüzden sanırım bu sektör için biraz fazla yaşlanıyorum .
Dez Blanchfield: Söyleyecektim, bizi orada çok yaşlandırdın.
Bert Scalzo: Evet, size 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. Hepimizin geleneksel olarak bir hata ayıklayıcıya girmek ve kodun üzerinden atlamak olarak düşündüğümüzden bahsediyor olabilirsiniz. Ama aynı zamanda insanlar kodlarını yazacaklar; burada ifadeleri kodunuza yapıştırırsınız ve belki de bir çıktı dosyası, bir izleme dosyası veya başka bir şey üretirsiniz ve böylece kodunuzu düzenlersiniz. Bunu hata ayıklama olarak sayabilirim, biraz daha zor, bunu yapmanın bir yolu, ama önemli. Ama aynı zamanda, ünlü baskı ifademiz var: izlemek ve insanlar aslında baskı ifadeleri koymak ve aslında bir araç gördüm - ve bu bir veritabanı aracı - nerede bir hata ayıklayıcı kullanmayı bilmiyorsanız, bir düğmeye basarsanız, baskı ifadelerini kodunuz boyunca yapıştırır ve işiniz bittiğinde başka bir düğmeye basar ve bunları çıkarır. Çünkü birçok insan böyle hata ayıklar.
Hata ayıklama nedenimiz iki yönlüdür: her şeyden önce, kodumuzu etkisiz hale getirecek şeyler bulmalıyız. Başka bir deyişle, bu tipik olarak bir mantık hatası olduğu veya bir iş gereksinimini kaçırdığımız anlamına gelir, ancak ne olduğu, kodun etkili olmadığıdır; yapmasını beklediğimiz şeyi yapmıyor. Diğer zaman gidip hata ayıklama yapıyoruz, verimlilik için ve bu bir mantık hatası olabilir, ama doğru olanı yaptım, yeterince hızlı bir şekilde geri gelmiyor. Şimdi, bu noktaya değiniyorum çünkü profiller ikinci senaryo için muhtemelen daha iyi ve hem hata ayıklayıcılar hem de profilciler hakkında konuşacağız. Ayrıca, uzaktan hata ayıklama kavramı da vardır; Bu önemlidir, çünkü kişisel bilgisayarınızda oturuyorsanız ve kodun veritabanında gerçekten yürütüldüğü bir veritabanına çarpan bir hata ayıklayıcı kullanıyorsanız, aslında uzaktan hata ayıklama olarak adlandırılan şeyi yapıyorsunuzdur. Farkında olmayabilirsiniz, ama olan bu. Ve sonra, bu hata ayıklayıcıları ile kırılma noktaları, izleme noktaları, adım atma ve adım atma ve diğer bazı ortak şeylere sahip olmak çok yaygındır, bunları bir anda ekran görüntüsünde göstereceğim.
Şimdi, profil oluşturma: birkaç farklı yoldan profil oluşturma yapabilirsiniz. Bazı insanlar, iş yükünün her şeyi yakaladığı yeri yakaladığını ve tekrar oynadığını, bunun profil oluşturma olarak kabul edildiğini söyleyecektir. Benim deneyim daha örnekleme yapılırsa daha iyi oldu. Her bir ifadeyi yakalamak için hiçbir neden yoktur, çünkü bazı ifadeler o kadar çabuk çalışabilir ki umursamıyorsunuz, gerçekten görmeye çalıştığınız şey, hangisi tekrar tekrar gösteriliyor, çünkü çok uzun koşuyorlar. Bu nedenle, bazen profil oluşturma, her şeyi yürütmek yerine örnekleme anlamına gelebilir. Ve tipik olarak, kullanabileceğiniz bir çeşit çıktı elde edersiniz, şimdi bir IDE geliştirme ortamının içinde görsel olabilir, burada size çeşitli kod satırlarının performansının bir histogramı gibi verebilir, ancak yine de bir izleme dosyası üretir.
Profilers ilk olarak 1979'da ortaya çıktı. Yani, bunlar da uzun süredir var. Kaynak tüketimini veya performans sorunlarını bulmak için harika, yani verimli bir şey. Genel olarak konuşursak, her ikisini de aynı anda yapan hata ayıklayıcılarla çalışmamıza rağmen, hata ayıklayıcıdan ayrı ve farklıdır. Ve sanırım profiller iki araçtan daha ilginç olsa da, yeterli sayıda insanın hata ayıkladığını düşünürsem, o zaman kesinlikle yeterli sayıda insan profili olmaz, çünkü on hata ayıklayıcıdan biri profil oluşturacak gibi görünüyor. Ve bu bir utanç, çünkü profilleme gerçekten büyük bir fark yaratabilir. Şimdi, veritabanı dilleri, daha önce bahsettiğimiz gibi, SQL'iniz var - ve yuvarlak pimi burada kare deliğe zorladık ve bir programlama dili olmaya zorladık - ve Oracle. Bu PL / SQL - bu yordamsal SQL - ve SQL Server, Transact-SQL, SQL-99, SQL / PSM - sanırım, Prosedür Saklı Modül. Postgres ona başka bir isim verir, DB2 yine başka bir isim, Informix, ama mesele herkes 3GL tipi yapıları zorladı; başka bir deyişle, FOR döngüleri, değişken bildirimlerde ve SQL'e yabancı olan diğer tüm şeyler artık bu dillerdeki SQL'in bir parçasıdır. Ve böylece, bir Visual Basic programı gibi bir PL / SQL veya Transact-SQL hata ayıklamak gerekir.
Şimdi, veritabanı nesneleri önemlidir, çünkü insanlar “Peki, bir veritabanında hata ayıklamak için ne yapmam gerekiyor?” Diyecektir. Ve cevap, veritabanında kod olarak depolayabileceğiniz her şey - eğer yapıyorsam T-SQL veya PL / SQL - ve nesneleri veritabanında saklıyorum, muhtemelen bir saklı yordam veya saklı işlevdir. Ama aynı zamanda tetikleyiciler de var: bir tetikleyici saklı bir prosedür gibidir, ancak bir tür olayı tetikler. Şimdi, tetikleyicilerindeki bazı insanlar bir kod satırı koyacak ve depolanmış bir prosedürü çağıracak, böylece tüm saklı kodlarını ve prosedürlerini koruyacaklar, ancak aynı kavram: her şeyi başlatan şey hala tetikleyicidir. Ve sonra Oracle olarak, paket denilen bir şey var, ki bu bir tür kütüphane gibi olacak. Paket adı verilen bir gruba 50 veya 100 saklı yordam koydunuz, bu da bir kütüphane gibi. İşte, eski yoldaki hata ayıklayıcı; bu aslında içeri girecek ve tüm bu hata ayıklama ifadelerini sizin için kodunuza yapıştıracak bir araçtır. Yani, hata ayıklama bloğu gördüğünüz her yerde, otomatik hata ayıklayıcı başlatma ve izleme, bunların hepsi bir araç tarafından sıkışmış. Kodun azınlığı olan bunun dışındaki satırlar, manüel olmayan hata ayıklama yöntemidir.
Ve bunu ortaya çıkarmamın nedeni, bunu elle yapmaya çalışıyorsanız, aslında tüm bu yazdırma ifadelerini kodda olduğundan daha fazla hata ayıklama kodu yazacaksınız. Yani, bu işe yarayabilir ve hiçbir şeyden daha iyi olsa da, bu hata ayıklamanın çok zor bir yoludur, özellikle de, bu şeyin çalışması 10 saat sürerse ve sorun nerede üçüncü satırda? Etkileşimli bir hata ayıklama oturumu yapsaydım, üç - beş dakika satırında bunu bilirdim - hey, burada bir sorun var, bırakabilirim. Ama bununla birlikte, tamamlanması için çalışmasını beklemeliyim ve sonra muhtemelen tüm bu baskı ifadelerini içeren bazı izleme dosyasına bakmam ve iğneyi samanlık. Yine, bu hiç yoktan iyidir, ama çalışmanın en iyi yolu olmaz. Şimdi, bu dosya önceki slayttan gelmiş gibi görünecektir; başka bir deyişle, programı çalıştırdım ve bu izleme dosyasında sadece bir sürü yazdırma ifadesi var ve bu aracılığıyla sifon yapabilir ve bulmam gereken şeyi bulabilirim veya edemeyebilirim. Yani, yine, bunun nasıl çalışacağından emin değilim.
Şimdi, etkileşimli hata ayıklayıcılar - ve programları yazmak için Visual Studio veya Eclipse gibi bir şey kullandıysanız, hata ayıklayıcılarınız vardı ve bunları diğer dillerinizle kullandınız - bunları burada veritabanınızla kullanmayı düşünmediniz. Ve orada, DB Artisan ve Rapid SQL gibi araçlar var, bu bir hata ayıklayıcı var Rapid SQL ve sol tarafta görebilirsiniz, "yinelenenleri kontrol et" adlı saklı bir prosedür var. Temel olarak, sadece aynı film başlığına sahip tabloda birden fazla satırım olup olmadığına bakıp bakacağım. Yani, veritabanı filmler içindir. Ve sağ tarafta, üstte üçüncü sırada, kaynak kodumu ortada gördüm, saat değişkenlerim ve çağrı yığını tepsilerim var, sonra altta bazı çıktı mesajları aldım. Ve burada önemli olan, eğer ilk kırmızı oka bakarsanız, bir değişkenin üzerine fareyle gidersem, aslında kodda adım attığım zaman, o anda o değişkende hangi değerin olduğunu görebiliyorum. Ve bu gerçekten yararlı, ve sonra kod aracılığıyla her seferinde bir satır basabilirim, yürütmek zorunda değilim, bir satır adım diyebilirim, ne olduğuna bakayım, başka bir satıra adım at, ne olduğunu göreyim ve bunu veritabanında yapıyorum. Bilgisayarımda Rapid SQL üzerinde oturmama ve veritabanım bulutta olmasına rağmen, yine de uzaktan hata ayıklamayı yapabilir ve buradan kontrol edebilir ve diğer herhangi bir dilde yaptığım gibi hata ayıklama yapabilirim.
Şimdi, bir sonraki ok - o DBMS çıktısına doğru, sağa doğru işaret eden küçük bir ok görebilirsiniz, imlecimin şu anda olduğu yer - yani başka bir deyişle, adım attım ve işte oradayım an. Bu yüzden, “Tekrar adım at” dersem, bir sonraki satıra gideceğim. Şimdi hemen altında kırmızı noktayı göreceksiniz. Bu bir kırılma noktası, “Hey, bu çizgilerin üzerinden geçmek istemiyorum” diyor. Sadece her şeyin üzerinden atlayıp o kırmızı noktaya ulaşmak istersem, koş düğmesine basabilirim ve koşacak Burada herhangi bir kesme noktası varsa ya da sonuna ya da bir kesme noktasına kadar durur ve sonra durur ve adımlamayı tekrar yapmama izin verir. Ve tüm bunların önemli ve güçlü olmasının nedeni, tüm bunları yaptığımda, ortada ve hatta altta olup bitenler - ama en önemlisi ortada - değişecek ve değişkenlerimdeki değerleri görebileceğim, Benim çağrı yığını izini görebilirsiniz, biliyorsunuz, ve böylece tüm bu kod boyunca adım olarak orada görüntülenir, böylece aslında ne olup olmadığını ve kod aslında nasıl olduğunu anlamak ve almak yürütme zamanında çalışma. Ve genellikle, eğer varsa, ya da onu yakalayacak kadar iyiysem bir sorun bulabilirim.
Tamam, şimdi bir profiller hakkında konuşacağım ve bu durumda, bu bir hata ayıklayıcı aracılığıyla görebildiğim bir profiler. Bazen ayrı olduklarını ve bazen birlikte olabileceğini söylediğimi hatırlıyor musunuz? Bu durumda ve tekrar Rapid SQL'deyim ve sol tarafta satır numaralarının yanında bir kenar boşluğu olduğunu görebiliyorum. Ve bu, her kod satırını yürütmek için gereken saniye veya mikrosaniye sayısıdır ve açıkça görebiliyorum, tüm zamanlarımın bir tablodan her şeyi seçtiğim tek bir FOR döngüsünde harcandığını görebiliyorum . Ve böylece, bu FOR döngüsünün içinde ne olursa olsun, muhtemelen bakmam gereken bir şeydir ve eğer daha iyi yapabilirsem, temettü ödeyecek. 0.90 veya 0.86 gibi satırlarda çalışarak herhangi bir iyileştirme elde etmeyeceğim; orada fazla zaman kalmadı. Şimdi, bu durumda ve tekrar, Rapid SQL'deyim, hata ayıklama ile karıştırılmış profillemeyi nasıl yapabileceğimi görüyorsunuz. Şimdi, güzel olan Rapid SQL de bunu başka şekilde yapmanıza izin veriyor. Hızlı SQL, “Biliyor musunuz? Hata ayıklayıcıda olmak istemiyorum, sadece bunu çalıştırmak istiyorum ve sonra grafiksel veya görsel olarak aynı tür bilgilere bakmak istiyorum. ”
Ve artık hata ayıklayıcıda olmadığımı ve programı çalıştırdığını ve yürütme tamamlandıktan sonra, bana bir şeyler anlatmam için grafikler verdi, böylece alıyor gibi görünen bir ifadem olduğunu görebiliyorum pasta grafiğinin çoğu ve eğer bakarsam, o ızgarayı aşağıya doğru görüyorum, satır 23, yine FOR döngüsü var: en çok zaman alıyor, aslında tüm pasta grafiğini koyu kırmızı çiğniyor. Ve bu, profil oluşturma için başka bir yol. Aracımızda “Kod Analisti” diyoruz. Ama temelde sadece bir hata ayıklayıcıdan ayrılmış bir profil oluşturucu. Bazı insanlar bunu ilk şekilde yapmayı sever, bazıları ise ikinci şekilde yapmayı sever.
Neden hata ayıklama ve profil oluşturma yapıyoruz? Bunun nedeni, dünyanın en büyük kodunu yazmak ve ücret zammı almak istediğimiz için değil - bu bizim nedenimiz olabilir, ancak bunu gerçekten yapma nedeni değil - işe doğru bir şey yapacağınıza söz verdiniz, programınızın etkili olacağına söz verdiniz. Hata ayıklayıcıyı 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. Zihinlerini okumamız ve her şeyi anında yapmamız gerekiyor. Başka bir deyişle, verimli olmalı. Ve böylece, profil oluşturucuyu bunun için kullanırdık. Şimdi, bu araçlar olmadan, yay ve ok ile iş takım elbiseli bu adam olduğuna gerçekten inanıyorum ve hedefe ateş ediyorsun ve gözlerini bağlıyorsun. Çünkü bir programın sadece statik koda bakarak nasıl çalıştığını ve nasıl sadece statik koda bakarak hangi satırın yürütmede gerçekten en fazla zaman harcayacağını nasıl anlayacaksınız? Bir kod incelemesi bunlardan bazılarını ortaya çıkarabilir veya getirmeyebilir, ancak bir kod incelemesinin hepsini bulacağının garantisi yoktur. Bir hata ayıklayıcı ve profiler kullanarak tüm bu hataları bulabilmelisiniz.
Tamam, burada gerçekten hızlı bir demo yapacağım. Ürünü itme niyetim değil, sadece bir hata ayıklayıcının neye benzediğini göstermek istiyorum, çünkü çoğu zaman insanlar “Daha önce bunlardan birini daha önce hiç görmedim.” Der ve ekran görüntüsü slaytlarında güzel görünüyor., ama hareket halindeyken neye benziyor? Burada, ekranımda DB Artisan ürünüm var; orada da bir hata ayıklayıcı var. DB Artisan DBA'lar için daha fazla, Rapid SQL geliştiriciler için daha fazla, ama DB Artisan kullanan geliştiriciler gördüm ve Rapid kullanan DBA'lar gördüm. Yani, ürünü yakalamayın. Ve burada, bir hata ayıklama yapma seçeneğim var, ancak hata ayıklamayı başlatmadan önce, kodu çalıştırmadan önce neye benzediğini görebilmeniz için bu kodu çıkaracağım. İşte ekran görüntüsündeki kodun aynısı, bu da kopyalarım için yaptığım kontrol. Ve bu hata ayıklamak istiyorum, bu yüzden hata ayıklama tuşuna basın. Ve şimdi, biraz zaman alıyor ve “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 gerçekleşiyor. Bu yüzden, oraya gitmek ve orada bir oturum oluşturmak, uzaktan hata ayıklama oluşturmak, oturumu o uzaktan hata ayıklama oturumuna bağlamak ve bir iletişim kanalı kurmak zorundaydı.
Şimdi, benim okum, üstte, birinci satırda, kodda olduğum yer. Ve orada üçüncü simgeye basarsam, bu da bir adımdır, o okun hareket ettiğini görürsünüz ve basmaya devam edersem, hareket etmeye devam eder. Şimdi, eğer bu FOR döngüsüne kadar gitmek istersem, çünkü sorunun burada olduğunu biliyorum, bir kesme noktası ayarlayabilirim. Bunu ayarladığımı sanıyordum. Ateş et, ekran yakalama anahtarlarımdan birini hata ayıklayıcı ile aynı tuşa eşledim, karışıklığa neden olan şey bu. Tamam, bu yüzden manuel olarak orada bir kesme noktası ayarlıyorum, o yüzden şimdi oraya gelene kadar bir adım, adım, adım, adım yapmak yerine, “Sadece devam et ve bu şeyi çalıştır” diyebilirim ve duracak. Beni kırılma noktasının olduğu yere götürdüğüne dikkat edin, bu yüzden şimdi bu döngüyü çalıştırma bağlamındayım, tüm değişkenlerimin neye ayarlandığını görebiliyorum, bu bir sürpriz değil, çünkü hepsini başlattım sıfıra. Ve şimdi, bu döngüye adım atabilir ve bu döngünün içinde neler olup bittiğine bakmaya başlayabilirim.
Yani, şimdi kiralarımdan bir seçim sayısı yapacağım ve o adamın üzerine fare ile gidip bakabilirim, o 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 kaçmasına izin vereceğim. Burada her şeyden geçmek istemiyorum; size göstermek istediğim şey, bir hata ayıklayıcı tamamlandığında, normal bir program gibi bitiyor. Kesme noktası ayarladım, bu yüzden koş dediğ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ı programın davranışını değiştirmiyor: Çalıştırıldığında, ben çalıştırmamış olsaydım aynı sonuçları almalıyım bir hata ayıklayıcı içinde.
Ve bununla birlikte demosu askıya alıp geri döneceğim çünkü soru ve cevaplarımız için zamanımız olduğundan emin olmak istiyoruz. Ve böylece, soru ve cevaplar için açacağım.
Eric Kavanagh: Pekala Robin, belki sizden bir soru ve sonra Dez'den bir çift?
Robin Bloor: Evet, elbette, bu büyüleyici buluyorum. Ben böyle şeyler üzerinde çalıştım, ama veritabanında böyle bir şey ile hiç çalışmadım. İnsanların profil oluşturucuyu ne için kullandıkları hakkında biraz fikir verebilir misiniz? Çünkü onlar bakıyorlar - çünkü ben öyle olduklarını varsayıyorum - performans sorunlarına bakıyorlar, bir veritabanının ne zaman ve bir kodun ne zaman aldığını ayırt etmenize yardımcı olacak mı?
Bert Scalzo: Biliyorsunuz, bu harika bir soru. Diyelim ki Visual Basic'te çalışıyorum ve Visual Basic'imin içinde bir Transact-SQL veya PL / SQL diyeceğim. PL / SQL yapmama izin verin, çünkü Oracle her zaman Microsoft araçlarıyla iyi oynamıyor. Visual Basic kodumu profilleme olabilir ve oradaki profil, "Hey, bu saklı yordamı çağırdı ve çok uzun sürdü" diyebilir. Ama sonra saklı yordama gidebilir ve depolanan bir veritabanı profili yapabilirim "Tamam, burada bulunan 100 ifadeden, soruna neden olan beş tane var" deyin ve birden çok profiler kullanmanız gereken bir etiket ekibi yapmanız gerekebilir.
Fikir, eğer performans probleminin veritabanınızda olduğunu söylerseniz, bir veritabanı profili samanlıkta iğneyi bulmanıza yardımcı olabilir. Size profilleme ile ortaya çıkan başka bir şey daha söylüyorum: bir milyon kez çağrılan bir kod parçanız varsa, ancak her milyon kez bir mikrosaniye alır, ancak bir milyon kez denir, profilin göstereceği şey, bu şey bu kadar zaman birimi için koştu. Bu yüzden kod son derece verimli olsa da, “Ooh, bu kod parçasına çok sık çağrı yapıyoruz. Belki de onu her kayıt işlemek yerine sadece sık sık çağırmalıyız ”veya başka bir şey. Ve böylece çok sık denilen verimli kodun nerede olduğunu bulabilirsiniz ve bu aslında bir performans problemidir.
Robin Bloor: Evet, bu harika. Bunu hiç yapmadım. Görüyorsunuz, tabii ki, veritabanı sorunları yaşadığımda, bir şekilde ya da başka bir şekilde ya veritabanı ile uğraşıyor ya da kodla uğraşıyordum; İkisiyle aynı anda asla baş edemedim. Ama orada, yine yapmadım - Asla prosedürleri sakladığımız uygulamaları oluşturmakla hiç ilgilenmedim, bu yüzden sanırım beni asla çılgına çeviren problemlerle karşılaşmadım, kodu bir veritabanı ve bir program arasında bölerek. Ama öyle, hepsini yap - Cevabın evet olacağını tahmin ediyorum, ama bu bir şekilde bir geliştirme ekibi faaliyetinin bir parçası, kırık bir şeyi düzeltmeye çalışırken ya da belki yeni bir şey getirmeye çalışırken birlikte uygulama. Ancak bunların hepsi çevrede beklediğim diğer tüm bileşenlerle uyumlu mu? Bunu tüm test paketlerimle ve yapacağım diğer tüm şeylerle ve proje yönetimi materyallerimle birlikte kırpabileceğimi bekleyebilir miyim?
Bert Scalzo: Evet, programlama veya geliştirme çabalarınızı yapmak herhangi bir yapılandırılmış sürecin parçası olabilir. Ve komik, geçen hafta bir web uygulaması geliştiren bir müşterim vardı ve veritabanları tarihsel olarak küçüktü ve bu yüzden çok iyi olmadıkları gerçeği programcılara asla zarar vermedi. Veritabanları yıllar içinde büyüdü ve şimdi bir web sayfasında 20 saniye sürüyor, “Oturum aç ve görmem için bana veri ver” ile ekranın gerçekten ortaya çıktığı zaman arasında bir performans sorunu. Ve sorunun hiçbir Java ya da başka herhangi bir yerinde olmadığını biliyorlardı. Ama binlerce saklı yordam vardı ve bu nedenle bu web sayfasının neden 20 saniye sürdüğünü öğrenmek için saklı yordamları profillemeye başlaması gerekiyordu. Ve aslında seçtikleri ifadelerden birinde Kartezyen bir birleşimi olduğunu gördük ve bunu bilmiyorduk.
Robin Bloor: Vay canına.
Bert Scalzo: Ama birisi bana bir kez dedi ki, “Peki nasıl Kartezyen bir araya gelip bilmiyorlardı?” Ve bu kulağa gerçekten korkunç gelecektir; Bazen SQL ile çok rahat olmayan bir programcı bana Kartezyen katılma gibi bir şey yapar, ama sonra sadece ilk kaydı bana geri verir, bu yüzden bir şeyim olduğunu biliyorum ve sadece ilkine ihtiyacım var. Ve böylece, sadece bir milyar rekor geri getirdiklerini ya da bir milyar rekor incelediklerini fark etmiyorlar, çünkü ilgilendiklerini aldılar.
Robin Bloor: Vay be, biliyorum, buna denir - iyi, belki de olması gerektiği kadar yetenekli olmayan insanlar açısından, Dez'in olayı buydu. Bir programcıysanız, herhangi bir komut vermenin ne anlama geldiğini bilmelisiniz. Demek istediğim, gerçekten, bu aptallık seviyesinin mazereti yok. Ayrıca, şu ya da bu şekilde, sadece bu konuda agnostik bir dil olduğunu varsayıyorum, çünkü bu tüm veritabanı tarafında odaklanıyor. Bunda haklı mıyım? Kodlama tarafında ne kullanırsanız kullanın aynı mıdır?
Bert Scalzo: Kesinlikle, bunu Fortran veya C veya C ++ ile yapabilirsiniz. Aslında, bazı Unix'lerde komut dosyaları için bile yapabilirsiniz; aslında aynı araçları sağlıyorlar. Ve sonra, hiçbir mazeret olmadan söylediklerinize bir saniye geri dönmek istiyorum. Programcılara bir mola vereceğim, çünkü programcıları otobüsün altına atmaktan hoşlanmıyorum. Ama sorun gerçekten akademik ortam çünkü programcı olmayı öğrenmeye gittiğinizde, her seferinde rekor bir düşünme öğretiliyorsunuz. Küme düşünme öğretilmez ve Yapılandırılmış Sorgu Dili veya SQL kümelerle çalışır; bu yüzden birlik, kesişme noktası ve eksi operatörü var. Ve bazen setler açısından hiç düşünmemiş bir kişi için vazgeçmek, bir anda kayıt işlemeyi bırakmak ve setlerle çalışmak çok zor olabilir.
Robin Bloor: Evet, bununla seninleyim. Yani, şimdi anladım, bu bir eğitim meselesi; Bence bu tamamen bir eğitim meselesi, bence programcıların usule göre düşünmeleri doğal. Ve SQL prosedürel değil, bildirim niteliğindedir. Aslında sadece “İstediğim budur ve nasıl yaptığını umursamıyorum” diyorsun, biliyor musun? Programlama dillerinde sık sık kollarınızı kıvırırsınız ve bir döngü yaparken sayıları yönetmenin bile minutisine girersiniz. Ben vereceğim -
Bert Scalzo: Hayır. Tamam, devam et.
Evet, bir profilin bir kerede bu rekor işlemeye devam edeceğini iyi bilen bir örnek daha getirdiğini söyleyecektim. Bazen, her seferinde kayıt mantığında iyi olan bir programcı, SQL programının nasıl yapılacağını anlayamaz. Diyelim ki iki FOR döngüsü yapıyor ve temelde bir birleştirme yapıyor, ancak bunu istemci tarafında yapıyor. Yani, birleştirme ile aynı etkiyi yapıyor, ancak bunu kendisi yapıyor ve bir profil bunu yakalayacaktır, çünkü muhtemelen birleştirme işlemini manuel olarak yapmak için veritabanı sunucusunun sizin için yapmasına izin vermekten daha fazla zaman harcarsınız.
Robin Bloor: Evet, bu bir felaket olurdu. Demek istediğim, sadece etrafta dolanıyorsun. Thrashing her zaman kötüdür.
Her neyse, Dez'e geçeceğim; Eminim bazı ilginç soruları var.
Dez Blanchfield: Teşekkür ederim, evet, biliyorum. Size otobüsün altına atmayan programcılara katılacağım. Demek istediğim, hayatımda çok uzun yıllar kendimi kodlayıcı olarak geçirdim, her seviyede, bildiğiniz gibi, söylediğiniz gibi, Unix makinesinin komut satırında oturuyordum ve bazı durumlarda bile dahil oldum bir donanım platformundan diğerine birkaç farklı Unix portunda. Ve orada yaşadığımız zorlukları hayal edebilirsiniz. Ama gerçek şu ki, dünyadaki her kodlayıcı ve komut dosyası için hapishane kartı. Her zaman, her zaman gerçekten sıkı yazmak bir roket bilimidir, her zaman, bir roket bilimidir. Dennis Ritchie ve Brian Kernahan gibi insanların ünlü bir hikayesi bağımsız olarak bir kod parçası üzerinde çalışıyor ve sonra bir kahve üzerinde kod inceleme sohbetine çıkıyor ve tam olarak aynı programda aynı kod parçasını yazdıklarını öğreniyor, aynı şekilde. Ve bunu C'de yaptılar. Ancak bu saf programlama seviyesi çok nadiren var.
Gerçek şu ki, günlük olarak, günde sadece 24 saat, haftada yedi gün var ve sadece işleri halletmeliyiz. Ve böylece, sadece geleneksel programcılar, DBA'lar ve kodlayıcılar ve kodlayıcılar ve sysadmin ve ağ yöneticileri ve güvenlik personeli ve bu günlerde vatandaşların veri tarafına kadar her şey söz konusu olduğunda; duyuyoruz, herkes sadece işini yapmaya çalışıyor. Ve bence bu her şeyden büyük paket servisi, demoyu çok sevdim ve bir dakika önce bizi orada bıraktığınız paket servisi çok sevdim, Robin'le bunun belirli bir şey olduğu gerçeği hakkında konuştum - belki de çok fazla değil bir niş - ancak kod ve SQL ve veritabanlarını sabitlemek için geçerli olduğu geniş bir alan. Ama bunu bir kabuk senaryosunda kurcalayabileceğinizi ve bazı sorunlar bulabileceğinizi duyduğum için gerçekten heyecanlandım, çünkü biliyorsunuz, bugünün ve çağın her zaman her şey için en düşük maliyetle çalışıyoruz.
Bir yerde 6 dolarlık bir gömlek satın almanın sebebi, birinin aslında üretim ve gemi ve lojistik olarak teslim edip satmak ve perakende satış yapmak ve 6 dolarlık gömleği almak için çevrimiçi ödemeler almak için yeterince ucuz bir sistem kurmasıdır. Mükemmel bir şekilde kod yazmaları için yılda 400.000 dolar ödenmişse bu gerçekleşmez; sadece tüm gelişim. Bu noktada, sanırım bize biraz daha içgörü kazandırmak için gerçekten seveceğim sorulardan biri, şu anda gördüğünüz insanların bu tür araçları profile yerleştiren insanların genişliği ve genişliği nedir? bir kod ve performans sorunları aramak? Başlangıçta, tarihsel olarak, nereden geliyorlar? Büyük mühendislik evleri oldular mı? Ve daha sonra, durum böyle mi, giderek daha fazla şirketin bu aracı veya bu araçları uyguladığını düşünerek, işi bitirmek için kimin işleri hallettiğini bilen kodlayıcılara yardım etmeye çalışmak için doğru muyum? ve kapıdan çıkarır mısın? Ve bazen hapisten çıkma kartına ihtiyacımız var mı? Tarihsel olarak daha fazla mühendislik odağı ve gelişimi olduğunu düşünmekte haklı mıyım? Şimdi, Robin'in dediği gibi, akademik bir yaklaşımla daha az alışıyoruz ve şimdi kendi kendine öğretilen veya kesip yapıştıran bir kod mu, yoksa sadece bir şeyler inşa etmek mi? Ve bu, ürünü şimdi alan insanlarla eşleşiyor mu?
Bert Scalzo: Evet, kesinlikle. Size çok özel bir örnek vereceğim, sadece işi yapmak istiyoruz, çünkü iş adamları mükemmellik istemiyor. Bilgisayarlı bir satranç oyunu gibi: satranç oyunu mükemmel cevabı aramıyor; makul bir süre içinde yeterince iyi bir cevap arar, bu şekilde programlıyoruz. Ama şimdi bulduğum şey, çoğu insanın birim testlerinin bir parçası olarak bir profiler istediklerini söylemek yerine - bu şekilde yapardım, çünkü bunu zaman kaybı olarak görmüyorum - olan şey şimdi bu daha sonra, bazen, eğer şanslıysak, entegrasyon testi veya stres testi sırasında yapılır. Ancak çoğu zaman, bir şeyin üretime girdiği bir yükselişin bir parçası, bir süre koştu, hatta yıllarca koştu ve şimdi iyi çalışmaz ve şimdi bunu profilleyeceğiz. 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 daha fazlası; Robin'i biliyorum ve kesinlikle öyleyim. Bence bu günler, özellikle gelişmeye ve sistem inşasına çevik yaklaşımlarda, bana göre, teknik borç kavramı çok gerçek bir şey ve aslında bunu projelerde açıklıyoruz. Demek istediğim, Media Lens ve diğerleri gibi günlük olarak kodlama yaptığımız kendi projelerimiz ve Bloor Grubu genelinde çeşitli şeyler var. Ve ne zaman bir şey inşa edersek, bir bakıyoruz, ona bakıyorum ve her zaman şu anda bunu düzeltmem için bana ne kadara mal olacağı bakış açısına bakıyoruz. oraya gidip çıkarabilir ve sonra bu şeyin kırılıp kırılmayacağını izleyin ve görün. Ve sonradan geri dönüp düzeltmem gerekeceğini bildiğim bu teknik borcu devral.
Yani, bunu son yedi gün içinde yaptım: Birkaç araç ve senaryo yazdım, birkaç parça Python dili yazdım ve bunu Mongo'nun arka ucuna konuşlandırdım. güzel ve temiz ve güvenli olduğundan emin olun, ancak daha büyük bulmacayı elde etmek için çalışmak için bu işleve ihtiyacım olduğunu bilerek ihtiyacım olan sorguyu alır; gerçek acımın olduğu yer burası. Ve böylece bu teknik borca katlanıyorsunuz ve bence bu sadece ara sıra bir şey değil, bence bu şu anda gelişmekte olan DNA'nın bir parçası. İnsanlar sadece - ihtiyatlı değil - sadece teknik borcun normal bir modus operandi türü bir sorun olduğunu kabul ediyorlar ve sadece buna katlanmak zorundalar. Teknik borca katlandığınız yer burası. Sanırım demoda bize gösterdiğiniz şeyle ilgili en iyi şey, kelimenin tam anlamıyla profil oluşturabilir ve bir şeyin ne kadar süreceğini izleyebilmenizdi. Ve bu muhtemelen en sevdiğim şeylerden biri. Yani, aslında profil oluşturma araçları oluşturdum - kodumuzu çalıştırmak ve döngülerin nerede olduğunu görmek için Sed ve Lex ve Orc'da araçlar geliştirirdik - böyle araçlar mevcut olmadan önce - ve gitmek için kod oluşturduğunuzda ve kendi kodunuzu gözden geçirirseniz, kendi kodunuzu gözden geçirmek zorunda kalmayacaksınız. Ama şimdi durum böyle değil. Bunu göz önünde bulundurarak, bunu diğerlerinden daha fazla alan belirli bir pazar segmenti var mı? Kitle gibi görmek-
Bert Scalzo: Ah, evet, senin için bir benzetme yapacağım ve programcı olmayanların bunu her zaman yaptığını göstereceğim. Çünkü hiç bir hata ayıklayıcı ve profilleme dersi veya oturumu öğretirsem, insanlara “Tamam, burada kaç kişi Microsoft Word'e giriyor ve hiçbir zaman yazım denetimini kullanmıyor?” Diye soracağım. Ve kimse elini kaldırmaz, çünkü belge yazmak için hepimiz İngilizce hatalar yapabileceğimizi biliyoruz ve böylece herkes yazım denetimini kullanıyor. Ve dedim ki, “Peki, IDE'nize Visual Basic gibi metin yazarken nasıl hata ayıklayıcı kullanmıyorsunuz? Aynı şey, bir yazım denetleyicisi gibi. ”
Dez Blanchfield: Evet, aslında, bu büyük bir benzetme. Gerçekten düşünmemiştim, itiraf etmeliyim ki aslında kullandığım birkaç araçla benzer bir şey yapıyorum. Aslında, bir, ODF, Eclipse ile benim en sevdiğim sadece orada kod kesmek ve yapıştırın ve hemen vurgulamak ve bazı sınıf çağrıda bir yazım hatası yaptığımı fark şeyler arıyor. Ve, ama şimdi böyle bir araçla ilginç, geri dönüp daha sonra bakmak yerine gerçek zamanlı olarak yapabilirsiniz, bu da onu yakalamak için güzel bir şey. Ama evet, bu sadece bir kelime işlemciye metin koymanın harika bir benzetmesi, çünkü bu ilginç bir uyandırma çağrısı, sadece bazı yazım hataları, hatta dilbilgisi hatası yaptığınızı anlayın, değil mi?
Bert Scalzo: Kesinlikle.
Dez Blanchfield: Yani, sanırım şu andan itibaren daha fazla yükseliş mi görüyorsunuz, demek istediğim, sorularıma cevap vermeden önce benden son soru belki de katılımcılar için. Bunu yapmak için yaklaşım etrafında bir çeşit öneri verecek olsaydınız - bunun retorik olduğunu varsayıyorum - gelişmeden önce erken girip bunu uygularken böyle bir durum ortaya çıkarıyor mu? Ya da ağırlıklı olarak inşa edip, hareket etmeye, bir şeyler inşa edip içeri girip daha sonra profil oluşturmaya çalıştığınız durum mu? Erken girme ve kodunuzun temiz olduğundan emin olun. Yoksa konuşlandırılmalarının bu bölümünü dikkate almaları gereken bir durum mu?
Bert Scalzo: İdeal olarak, bunu açık bir şekilde yapacaklardı, ancak herkes işlerini halletmek zorunda oldukları acele, telaş dünyasında olduğu için, çözemedikleri bir performans sorunuyla karşılaşana kadar bunu yapmamaya eğilimliler sanal makineye daha fazla CPU ve bellek ekleyerek.
Dez Blanchfield: Evet. Yani, eğer ilginç bir şeyden bahsettin, eğer çabucak yapabilirsem? Daha önce bunun herhangi bir yerden çalıştırılabileceğini ve arka uçtaki veritabanıyla konuşabileceğini söylemiştiniz. Bu, şimdi konuştuğumuz bimodal konseptiyle, kurum içi / kurum dışı bulutla, şeylerin görünüşüyle, günün sonunda, arka uçla konuşup görebiliyorsa, rahat kod gerçekten umursamıyor, değil mi?
Bert Scalzo: Kesinlikle, evet, bunu bulutta çalıştırabilirsiniz.
Dez Blanchfield: Mükemmel, çünkü sanırım yeni cesur dünyamız nereye gidiyor. Ee Eric. Şimdi size geri döneceğim ve burada birkaç sorumuz olduğunu göreceğim ve bir saat geçmesine rağmen katılımcılarımızın hala bizimle kalmasını istiyorum.
Eric Kavanagh: Evet, orada birkaç kişi var, sadece hızlı bir yorum yapacağım: Bert, bence mecaz, yazım denetimini kullanmak için kullandığınız benzetme çok parlak. Bu bir ya da iki blog'a layık, açıkçası, çünkü yaptığınız şeyin ne kadar değerli olduğunu ve bir hata ayıklayıcıyı kullanmanın en iyi uygulama şeklini çerçevelemek için iyi bir yol düzenli olarak, değil mi? Bahse girerim bunu dışarı attığınızda başınızı sallamanız gerekir, değil mi?
Bert Scalzo: Kesinlikle, çünkü onlara söylediklerim, “Belgelerim üzerinde neden bir yazım denetimi yapıyorum? Aptal yazım hatalarından utanmak istemiyorum. ”Eh, aptal kodlama hatalarından utanmak istemiyorlar!
Eric Kavanagh: Doğru. Evet kesinlikle. Millet, burada bir saat beş dakika boyunca yandık, zamanınız ve ilginiz için hepinize çok teşekkürler. Tüm bu web sohbetlerini arşivliyoruz, istediğiniz zaman geri dönüp onları kontrol etmekten çekinmeyin. Bu bağlantıları bulmak için en iyi yer muhtemelen techopedia.com'dur, bu yüzden bunu buraya bu listeye ekleyeceğiz.
Ve bununla, sana veda edeceğiz millet. Bir kez daha, iyi iş, Bert, IDERA'daki arkadaşlarımıza teşekkürler. Bir dahaki sefere seninle konuşacağız, aslında önümüzdeki hafta seninle konuşacağız. Kendine iyi bak! Güle güle.
