Oleh Staf Techopedia, 15 Maret 2017
Takeaway: Host Eric Kavanagh membahas debugging dan profiling basis data dengan Dr. Robin Bloor, Dez Blanchfield dan Bert Scalzo dari IDERA.
Anda saat ini belum masuk. Silakan masuk atau daftar untuk melihat video.
Eric Kavanagh: Oke, tuan-tuan dan nyonya-nyonya, ini jam 4:00 timur pada hari Rabu, dan tentu saja itu artinya.
Robin Bloor: Tidak bisa mendengarmu, Eric.
Eric Kavanagh: Saya ada di sana beberapa hari yang lalu, jadi Anda tidak sendirian. Tapi topik hari ini sangat menarik. Ini adalah jenis hal yang ingin Anda pastikan terjadi di latar belakang di perusahaan Anda, kecuali jika Anda adalah orang yang melakukannya, dalam hal ini Anda ingin memastikan Anda melakukannya dengan benar. Karena kita sedang berbicara tentang debugging. Tidak ada yang suka bug, tidak ada yang suka ketika perangkat lunak berhenti bekerja - orang marah, pengguna menjadi tidak ramah. Itu tidak baik. Jadi, kita akan berbicara tentang "Respon Cepat: Debugging dan Profiling Database untuk Penyelamatan."
Ada titik tentang dirimu yang sebenarnya, pukul aku di Twitter, @eric_kavanagh tentu saja.
Tahun ini panas. Dan debugging akan menjadi panas, apa pun yang terjadi. Ini benar-benar akan menjadi salah satu masalah yang tidak akan pernah hilang, tidak peduli seberapa bagus kita dalam hal ini, akan selalu ada masalah, jadi kuncinya adalah bagaimana Anda sampai ke tempat Anda bisa menyelesaikan masalah itu dengan cepat? Idealnya, Anda memiliki programmer yang hebat, lingkungan yang hebat, di mana tidak terlalu banyak kesalahan, tetapi seperti kata pepatah lama, "Kecelakaan terjadi dalam keluarga terbaik." Dan hal yang sama berlaku untuk organisasi. Jadi, hal ini terjadi, itu akan terjadi, pertanyaannya adalah apa yang akan menjadi solusi Anda untuk menghadapinya dan menyelesaikan masalah itu?
Kita akan mendengar dari Dr. Robin Bloor, kemudian Dez Blanchfield kita sendiri dari bawah, dan tentu saja, teman baik kita, Bert Scalzo, dari IDERA. Dan faktanya, saya akan menyerahkan kunci kepada Robin Bloor, bawa pergi. Lantai adalah milikmu.
Robin Bloor: Oke. Ini adalah topik yang menarik. Saya pikir karena Dez mungkin akan melanjutkan tentang teknik aktual dan cerita perang tentang debugging, saya pikir saya hanya akan melakukan diskusi latar belakang sehingga kita harus mendapatkan gambaran yang lengkap tentang apa yang terjadi. Saya melakukan ini dalam waktu yang lama, dan saya dulunya adalah seorang pembuat kode, jadi seperti itu, dan saya hampir tergoda dengan presentasi ini untuk mulai menambahkan lirik tentang ide open source tetapi saya pikir saya akan menyerahkannya kepada orang lain.
Berikut daftar bug terkenal, dan sebagian besar masuk ke daftar teratas siapa pun, pada dasarnya, semua kecuali dua yang terakhir menelan biaya setidaknya $ 100 juta. Yang pertama adalah Mars Climate Orbiter, tersesat di ruang angkasa dan itu karena masalah pengkodean, di mana orang bingung unit metrik dengan (tertawa) kaki dan inci. Ariane Five Flight 501 ada ketidakcocokan antara mesin yang dinyalakan dan komputer yang seharusnya menjalankan roket ketika diluncurkan. Banyak kegagalan komputer, meledaknya roket, berita utama. Pipa gas Soviet pada tahun 1982, dikatakan sebagai ledakan terbesar dalam sejarah planet ini; Saya tidak yakin apakah itu. Rusia mencuri beberapa perangkat lunak kontrol otomatis, dan CIA menyadari bahwa mereka akan melakukan itu dan memasukkan bug ke dalamnya, dan Soviet mengimplementasikannya tanpa pengujian. Jadi, hancurkan pipa, berpikir itu lucu.
Cacing Morris adalah percobaan pengkodean, yang tiba-tiba menjadi cacing yang rakus yang menyerang semua orang - itu tampaknya menyebabkan kerusakan senilai $ 100 juta; itu perkiraan tentu saja. Intel membuat kesalahan terkenal dengan chip matematika - instruksi matematika pada chip Pentium pada tahun 1993 - yang seharusnya menelan biaya lebih dari $ 100 juta. Program Maps Apple mungkin merupakan peluncuran terburuk dari apa pun yang pernah dilakukan Apple. Orang yang mencoba menggunakannya, maksud saya, seseorang mengemudi di sepanjang 101, dan menemukan bahwa Peta Apple mengatakan bahwa mereka berada di tengah Teluk San Francisco. Jadi, orang-orang mulai menyebut aplikasi Apple Maps sebagai iLost. - Pemadaman terpanjang kami pada tahun 1990 - hanya menarik dari sudut pandang biaya seperti itu - AT&T keluar selama sekitar sembilan jam dan harganya sekitar $ 60 juta untuk panggilan jarak jauh.
Dan saya berada di sebuah perusahaan asuransi Inggris, dan database, mereka menerapkan versi baru dari database dan mulai menghapus data. Dan saya ingat itu dengan sangat baik, karena saya dipanggil setelahnya untuk ikut serta dalam beberapa jenis pemilihan basis data karena itu. Dan sangat menarik bahwa mereka telah mengambil versi baru dari database, dan mereka memiliki serangkaian tes yang mereka lakukan untuk versi baru dari database yang telah melewati semua tes. Itu menemukan cara yang sangat jelas untuk menghapus data.
Jadi, bagaimanapun, itu saja. Saya pikir saya akan berbicara tentang ketidakcocokan impedansi dan SQL yang dikeluarkan. Sangat menarik bahwa database relasional menyimpan data dalam tabel dan coder cenderung memanipulasi data dalam struktur objek yang benar-benar tidak memetakan dengan sangat baik ke tabel. Dan karena itu, Anda mendapatkan apa yang disebut ketidakcocokan impedansi, dan seseorang harus menghadapinya dengan cara tertentu. Tetapi apa yang sebenarnya terjadi, karena satu model, model coder dan database model lain, tidak terlalu selaras. Anda mendapatkan bug yang tidak akan terjadi jika industri telah membangun hal-hal yang bekerja bersama, yang menurut saya lucu. Jadi, pada dasarnya, di sisi coders, ketika Anda mendapatkan hierarki itu bisa berupa tipe, itu bisa menghasilkan set, itu bisa kemampuan API yang buruk, itu bisa banyak hal yang hanya membuang hal-hal dalam hal interaksi dengan database. Tetapi hal yang paling bagi saya, sangat menarik; selalu membuat saya takjub bahwa Anda memiliki penghalang SQL ini yang juga semacam impedansi dengan cara bahwa coders dan database bekerja satu sama lain. Jadi, SQL memiliki pengenalan data, yang baik-baik saja dan memiliki DML untuk memilih, memproyeksikan dan bergabung, yang baik-baik saja. Anda dapat membuang banyak kemampuan dalam hal mendapatkan data dari database dengan itu. Tetapi memiliki sedikit bahasa matematika untuk melakukan sesuatu. Ini memiliki sedikit ini dan itu, dan memiliki sedikit hal berbasis waktu. Dan karena itu, SQL adalah alat yang tidak sempurna, jika Anda suka, untuk mendapatkan data. Jadi, orang-orang basis data membangun prosedur tersimpan untuk tinggal di database dan alasan untuk prosedur tersimpan yang tinggal di sana adalah bahwa Anda tidak benar-benar ingin melempar data bolak-balik ke suatu program.
Untuk beberapa fungsionalitas adalah data yang sangat spesifik, jadi itu bukan hanya integritas referensial dan penghapusan cascading dan hal-hal seperti itu, basis data mengurus semua yang Anda lakukan secara tiba-tiba dalam fungsionalitas dalam database, yang tentu saja berarti bahwa fungsi untuk suatu aplikasi dapat dibagi antara coder dan database itu sendiri. Dan itu membuat pekerjaan menerapkan beberapa jenis fungsi sangat sulit dan karenanya lebih rentan kesalahan. Jadi, itulah satu sisi dari permainan basis data, karena itu berarti bahwa Anda telah mendapatkan banyak implementasi misalnya, bahwa saya telah terlibat dalam basis data relasional, ada banyak sekali kode yang berada dalam prosedur tersimpan yang ditangani terpisah dari kode yang ada di aplikasi. Dan sepertinya hal yang sangat aneh, harusnya cukup pintar dalam melakukan berbagai hal.
Saya pikir saya juga akan berbicara tentang kinerja database karena kesalahan kinerja sering dianggap sebagai bug, tetapi pada dasarnya Anda dapat memiliki hambatan pada CPU, pada memori, pada disk, pada jaringan dan Anda dapat memiliki masalah kinerja karena mengunci . Idenya adalah bahwa pembuat kode tidak benar-benar perlu khawatir tentang kinerja dan database sebenarnya akan bekerja dengan baik. Seharusnya dirancang agar pembuat kode tidak perlu tahu. Namun, Anda mendapatkan desain database yang buruk, Anda mendapatkan desain program yang buruk, Anda mendapatkan konkurensi dalam pencampuran beban kerja, yang juga dapat menyebabkan masalah kinerja. Anda mendapatkan load balancing, Anda mendapatkan perencanaan kapasitas, pertumbuhan data - yang dapat menyebabkan database berhenti, atau melambat. Ini hal yang menarik, ketika database hampir penuh, mereka melambat. Dan Anda dapat memiliki masalah lapisan data dalam hal replikasi dan kebutuhan untuk mereplikasi dan kebutuhan untuk melakukan backup dan pemulihan. Bagaimanapun, itu gambaran umum.
Satu-satunya hal yang ingin saya katakan adalah bahwa debugging basis data hanya dapat menjadi sesuatu yang berat dan tidak sepele - dan saya mengatakan bahwa karena saya telah melakukan banyak hal - dan Anda akan sering menemukan itu seperti semua situasi dalam debugging yang saya lakukan. yang pernah dialami adalah, adalah hal pertama yang Anda lihat berantakan. Dan Anda harus mencoba dan pergi dari kekacauan ke mencari tahu bagaimana kekacauan itu terjadi. Dan seringkali ketika Anda melihat masalah basis data semua yang Anda lihat adalah data yang korup dan Anda berpikir, "Bagaimana itu bisa terjadi?"
Ngomong-ngomong, aku akan meneruskan pada Dez, yang mungkin akan mengatakan lebih banyak kata-kata bijak daripada yang kukatakan. Saya tidak tahu bagaimana mengoper bola, Dez.
Eric Kavanagh: Saya akan menyerahkannya, stand by, tunggu.
Suara otomatis: Garis peserta dibisukan.
Eric Kavanagh: Baiklah, tunggu sebentar, izinkan saya memberi Dez bola.
Dez Blanchfield: Terima kasih, Eric. Ya, Dr. Robin Bloor, Anda memang paling benar: ini adalah topik, serangga seumur hidup jika Anda mau mengampuni permainan kata-kata itu, maaf saya tidak bisa menahan diri untuk hal itu. Semoga Anda dapat melihat layar pertama saya di sana, permintaan maaf saya untuk masalah ukuran font di atas. Topik bug adalah kuliah sepanjang hari, dalam banyak kasus menurut pengalaman saya. Ini adalah topik yang sangat luas dan luas, jadi saya akan memfokuskan pada dua bidang utama, khususnya konsep tentang apa yang kami anggap sebagai bug, tetapi masalah pemrograman. Saya pikir hari-hari ini memperkenalkan bug per se umumnya akan diambil oleh lingkungan pengembangan terintegrasi, meskipun mereka mungkin bug yang sudah berjalan lama. Tetapi seringkali ini lebih merupakan kasus kode profiling dan dimungkinkan untuk menulis kode yang berfungsi, yang seharusnya berupa bug. Jadi, slide judul saya di sini, saya sebenarnya memiliki salinan ini dalam resolusi sangat tinggi A3, tetapi sayangnya itu hancur dalam perpindahan rumah. Tapi ini adalah catatan tulisan tangan pada lembar pemrograman dari sekitar tahun 1945, di mana konon beberapa orang di Universitas Harvard di AS, membangun kedua mesin mereka yang disebut Mark II. Mereka men-debug beberapa masalah, dalam bahasa yang sama, tetapi mereka berusaha menemukan kesalahan, dan ternyata ada sesuatu yang sedikit berbeda dari apa yang merupakan perangkat keras dan masalah perangkat lunak yang seharusnya muncul.
Jadi, mitos urban adalah bahwa pada putaran sekitar 9 September 1945, sebuah tim di Universitas Harvard sedang mencabut sebuah mesin, mereka menemukan sesuatu yang mereka sebut "relay tujuh puluh" - pada masa itu pemrograman dilakukan dalam arti fisik, Anda melukai kode di sekitar papan, dan itulah cara Anda memprogram mesin secara efektif - dan mereka menemukan nomor relay tujuh puluh ini ada yang salah dengan itu, dan ternyata istilah "bug" yang sebenarnya muncul karena secara harfiah adalah ngengat - konon ada adalah seekor ngengat yang terjepit di antara sepotong kawat tembaga dari satu tempat ke tempat lain. Dan ceritanya, Grace Hopper yang legendaris sebagai keterangan ini, untuk slide judul saya, "kasus aktual bug yang ditemukan" mengutip tanda kutip.
Tetapi seperti yang disoroti Robin sebelumnya dalam slide pertamanya, konsep bug berjalan sejauh yang bisa kita bayangkan manusia melakukan komputasi, konsep seperti tambalan. Istilah "tambalan" berasal dari selembar kaset yang sebenarnya ditempel di atas lubang pada kartu punch. Tapi intinya, adalah istilah "debugging" keluar dari konsep menemukan bug di mesin fisik. Dan sejak itu, kami telah menggunakan terminologi itu untuk mencoba menangani masalah, tidak hanya sebagai masalah pengkodean dalam program yang tidak dikompilasi, tetapi sebagai program yang tidak berjalan dengan baik. Dan secara khusus belum diprofilkan hanya menemukan hal-hal seperti loop yang tidak pernah berakhir yang tidak menuju ke mana-mana.
Tapi kami juga punya skenario, dan saya pikir saya akan memasukkan beberapa slide lucu sebelum saya masuk ke sedikit lebih detail. Inilah kartun klasik, yang disebut XKCD di web, dan kartunis itu memiliki beberapa pandangan lucu di dunia. Dan yang ini tentang seorang anak bernama "Little Bobby Tables" dan konon orang tuanya menamai bocah ini Robert '); DROP TABEL Siswa; - dan itu disebut, dan semacam "Hai, ini sekolah anak Anda mengalami masalah komputer, " dan orang tua menjawab, "Ya ampun, apakah dia memecahkan sesuatu?" Dan guru itu berkata, "Ya, Di satu sisi, "dan guru bertanya, " apakah Anda benar-benar nama anak Anda Robert '); DROP TABLE Students; -? ”Dan orang tua itu berkata, “ Oh ya, Bobby Tables kecil yang kita panggil dia. ”Lagi pula, mereka melanjutkan dengan mengatakan bahwa mereka sekarang telah kehilangan catatan siswa tahun ini, saya harap Anda bahagia. Dan jawabannya adalah, "Ya, Anda harus membersihkan dan membersihkan input basis data Anda." Dan saya menggunakan itu berkali-kali untuk membicarakan beberapa masalah yang kita miliki dalam menemukan hal-hal dalam kode, yang sering kali kode tidak melihat data. demikian juga.
Satu lagi yang lucu, saya tidak tahu apakah ini asli atau tidak - saya curiga ini tipuan - tapi sekali lagi, itu juga menyentuh tulang lucu saya. Seseorang mengubah plat nomor di bagian depan mobil mereka, ke pernyataan serupa yang menyebabkan database jatuh di kamera kecepatan dan sebagainya yang menangkap plat nomor mobil. Dan saya selalu menyebutnya sebagai hal yang saya ragukan setiap programmer mengantisipasi tabrak lari dari kode mereka oleh kendaraan bermotor yang sebenarnya, tetapi tidak pernah meremehkan itu - kekuatan geek yang marah.
(Tawa)
Tapi ini mengarah ke poin kunci saya, saya kira, dan itu adalah bahwa pada suatu waktu, kita bisa men-debug dan kode profil sebagai manusia biasa. Tetapi saya sangat berpandangan bahwa waktu telah berlalu, dan secara anekdot dalam pengalaman saya, yang pertama - dan ini akan membuat saya sangat tua, saya yakin; Robin Anda dipersilakan mengolok-olok saya untuk ini - tetapi secara historis saya datang dari latar belakang pada usia 14 berkeliaran di ujung kota, dan mengetuk pintu pusat data yang disebut "Data Com" di New Selandia dan bertanya apakah saya bisa mendapatkan uang saku di sekolah dengan mengantar bus pulang, sekitar 25 km perjalanan setiap hari, dengan meletakkan kertas di printer, dan kaset di drive tape, dan hanya menjadi admin umum. Dan anehnya mereka memberi saya pekerjaan. Tetapi seiring berjalannya waktu, saya berhasil masuk ke dalam kepegawaian dan menemukan programmer dan menyadari bahwa saya suka coding dan menjalani proses menjalankan skrip dan pekerjaan batch, yang pada akhirnya masih kode. Anda harus menulis skrip dan pekerjaan batch yang terlihat seperti program mini dan kemudian melalui seluruh proses duduk di 3270 menulis kode terminal dengan tangan.
Bahkan, pengalaman pertama saya adalah di terminal teletype, yang sebenarnya adalah printer fisik 132-kolom. Pada dasarnya, pikirkan seperti mesin tik yang sangat tua dengan kertas yang menggulungnya, karena mereka tidak memiliki tabung CRT. Dan debugging kode pada itu adalah masalah yang sangat non-sepele, jadi Anda cenderung menulis semua kode Anda dengan tangan, dan kemudian bertindak seperti juru ketik, melakukan yang terbaik untuk tidak mendapatkan kesalahan untuk menyelinap masuk, karena sangat frustasi harus memberitahu editor satu baris untuk pergi ke baris tertentu dan kemudian mencetak baris dan kemudian ketik kembali. Tapi sekali waktu, itu adalah bagaimana kami menulis kode dan itulah cara kami men-debug, dan kami menjadi sangat, sangat pandai dalam hal itu. Dan faktanya, itu memaksa kami untuk memiliki teknik pemrograman yang sangat bagus, karena sungguh merepotkan untuk memperbaikinya. Tetapi perjalanan kemudian berjalan - dan kita semua akrab dengan ini - ia beralih dari pengalaman terminal 3270 di dunia saya, ke Digital Equipment VT220 di mana Anda dapat melihat hal-hal di layar, tetapi sekali lagi, Anda hanya melakukan hal yang sama Anda melakukannya pada jenis kertas format cetak hanya pada CRT, tetapi Anda dapat menghapus lebih mudah dan Anda tidak memiliki suara "dit dit dit dit".
Dan kemudian Anda tahu, terminal Wyse - seperti Wyse 150, mungkin antarmuka favorit saya ke komputer - dan kemudian PC dan kemudian Mac, dan kemudian hari ini GUI dan ID modern yang berbasis web. Dan serangkaian program melalui itu, pemrograman dalam satu dan assembler dan PILOT dan Logo dan Lisp dan dan Fortran dan Pascal dan bahasa yang mungkin membuat orang merasa ngeri. Tetapi ini adalah bahasa yang memaksa Anda untuk menulis kode yang baik; mereka tidak membiarkan Anda lolos dengan praktik buruk. C, C ++, Java, Ruby, Python - dan kita semakin jauh ke tahap pemrograman, kita mendapatkan lebih banyak script-seperti, kita semakin dekat ke Structured Query Language dan bahasa-bahasa seperti PHP yang sebenarnya digunakan untuk memanggil SQL. Inti dari memberi tahu Anda bahwa, berasal dari latar belakang saya, saya belajar sendiri dalam banyak hal dan orang-orang yang memang membantu saya belajar, mengajari saya praktik pemrograman yang sangat baik dan praktik yang sangat baik di sekitar desain dan proses untuk memastikan saya tidak perkenalkan kode kereta.
Metode pemrograman hari ini, hal-hal seperti, misalnya, Structured Query Language, SQL, itu sangat kuat, bahasa query sederhana. Tetapi kami telah mengubahnya menjadi bahasa pemrograman dan saya tidak benar-benar percaya bahwa SQL dirancang untuk menjadi bahasa pemrograman modern, tetapi kami cenderung mengubahnya menjadi seperti itu. Dan itu menimbulkan banyak masalah, karena kita berpikir dari dua sudut pandang: dari sudut pandang pengkodean dan dari sudut pandang DBA. Sangat mudah untuk datang dan memperkenalkan bug untuk hal-hal seperti teknik pemrograman yang buruk, upaya malas dalam menulis kode, kurangnya pengalaman, kesal hewan peliharaan klasik yang saya miliki misalnya dengan orang-orang SQL yang melompat di Google dan mencari sesuatu dan menemukan situs web yang mendapat contoh dan melakukan copy dan paste kode yang ada. Dan kemudian mereplikasi pengkodean yang buruk, malpraktek dan memasukkannya ke dalam produksi, karena kebetulan memberi mereka hasil yang mereka inginkan. Anda punya tantangan lain, misalnya, hari ini kita semua bergegas menuju ini, apa yang kita sebut perlombaan ke nol: mencoba melakukan segalanya dengan sangat murah dan begitu cepat, sehingga kita memiliki skenario di mana kita tidak menggunakan yang lebih rendah - staf yang dibayar Dan saya tidak bermaksud itu dengan cara yang tidak jujur, tapi kami tidak mempekerjakan tenaga ahli untuk setiap pekerjaan yang memungkinkan. Sekali waktu ada hubungannya dengan komputer adalah ilmu roket; itu terlibat dalam hal-hal yang meledak dan sangat keras, atau pergi ke luar angkasa atau insinyur adalah pria dan wanita yang sangat berkualitas yang telah melakukan gelar dan memiliki pendidikan yang ketat yang membuat mereka tidak melakukan hal-hal gila.
Saat ini, ada banyak orang masuk ke pengembangan dan desain dan database yang belum memiliki pengalaman bertahun-tahun, belum tentu memiliki pelatihan atau dukungan yang sama. Dan Anda berakhir dengan skenario hanya amatir tradisional versus ahli. Dan ada garis yang terkenal, saya benar-benar tidak ingat siapa yang membuat kutipan, garisnya berbunyi, "Jika Anda berpikir mahal mempekerjakan seorang ahli untuk melakukan pekerjaan, tunggu sampai Anda mempekerjakan beberapa amatir yang menciptakan masalah dan Anda harus membersihkannya. ”Dan SQL memiliki masalah itu, dan itu sangat, sangat mudah dipelajari, sangat mudah digunakan. Tapi menurut saya, ini bukan bahasa pemrograman yang sempurna. Sangat mudah untuk melakukan hal-hal seperti melakukan pilih bintang dari mana saja dan menarik semua itu ke dalam bahasa pemrograman yang Anda lebih nyaman dengan seperti PHP dan Ruby atau Python, dan menggunakan bahasa pemrograman yang secara alami Anda kenal, untuk melakukan manipulasi data, daripada melakukan kueri yang lebih kompleks dalam SQL. Dan kita melihat ini banyak, dan kemudian orang bertanya-tanya mengapa database berjalan lambat; itu karena sejuta orang mencoba membeli tiket dari sistem tiket online, di mana ia memilih bintang terpilih dari mana saja.
Nah, itu contoh yang sangat ekstrem, tetapi Anda mendapatkan poin dari semua itu. Jadi, untuk benar-benar memukul titik itu di rumah, inilah contoh yang sering saya bawa-bawa. Saya penggemar berat matematika, saya suka teori chaos, saya suka set Mandelbrot. Di sisi kanan ada rendition dari set Mandelbrot, yang saya yakin kita semua kenal. Dan di sebelah kiri ada sepotong SQL yang benar-benar menerjemahkannya. Sekarang, setiap kali saya meletakkan ini di layar di suatu tempat, saya mendengar ini “Ya Tuhan, seseorang membuat seri Mandelbrot dengan SQL, apakah Anda serius? Itu gila! ”Nah, intinya adalah untuk menggambarkan apa yang baru saja saya uraikan di sana, dan itu adalah ya, sebenarnya Anda sekarang dapat memprogram hampir semua hal dalam SQL; ini adalah bahasa pemrograman modern yang sangat berkembang, kuat, dan modern. Ketika awalnya itu adalah bahasa query, itu dirancang hanya untuk mendapatkan data. Jadi, sekarang kami memiliki konstruksi yang sangat kompleks dan kami memiliki prosedur tersimpan, kami punya metodologi pemrograman yang diterapkan ke bahasa dan itu sangat mudah untuk praktik pemrograman yang buruk, kurangnya pengalaman, kode cut-and-paste, staf bergaji rendah berusaha menjadi staf bergaji tinggi, orang-orang yang berpura-pura tahu, tetapi mereka harus belajar di tempat kerja.
Berbagai macam hal di mana profil kode dan apa yang kita sebut sebagai debugging, yang tidak begitu banyak menemukan bug yang menghentikan program dari bekerja, tetapi bug yang hanya merusak sistem dan kode terstruktur buruk. Ketika Anda melihat layar ini sekarang, dan Anda berpikir, itu hanya, itu agak imut dan Anda berpikir, "Wow, grafik yang sangat bagus, saya ingin sekali menjalankannya." Tetapi bayangkan menjalankannya dengan logika bisnis . Kelihatannya cukup rapi, tetapi ia berbicara teori chaos yang dibuat secara matematis secara grafis, tetapi ketika Anda berpikir tentang apa yang berpotensi digunakan dalam beberapa logika bisnis, Anda mendapatkan gambar dengan sangat cepat. Dan untuk benar-benar menggambarkan hal itu - dan saya minta maaf warnanya terbalik, seharusnya latar belakang hitam dan teks hijau menjadi layar hijau, tetapi Anda masih bisa membacanya.
Saya pergi dan melihat sekilas contoh apa yang berpotensi Anda lakukan jika Anda benar-benar gila dan tidak punya pengalaman apa pun dan datang dari latar belakang pemrograman yang berbeda dan menerapkan suka-suka C ++ ke SQL, untuk benar-benar menggambarkan maksud saya, sebelum Saya menyerahkan kepada tamu terpelajar kami dari IDERA. Ini adalah kueri terstruktur yang ditulis seperti C ++, tetapi dikodekan dalam SQL. Dan sebenarnya dieksekusi, tetapi dieksekusi selama sekitar tiga hingga lima menit. Dan itu menarik kembali seolah-olah satu baris data dari banyak basis data, banyak gabungan.
Sekali lagi, intinya adalah bahwa jika Anda tidak memiliki alat yang benar, jika Anda tidak memiliki platform dan lingkungan yang benar untuk dapat menangkap hal-hal ini, dan mereka masuk ke dalam produksi, dan Anda memiliki 100.000 orang memukul sistem setiap hari, atau jam, atau menit, segera Anda berakhir dengan pengalaman Chernobyl di mana setrika besar mulai melebur dan mengubur dirinya sendiri ke inti planet ini, karena potongan kode itu seharusnya tidak pernah masuk ke dalam produksi. Sistem dan alat Anda, permisi, harus mengambilnya sebelum mendekati - bahkan melalui proses pengujian, bahkan melalui UAT dan integrasi sistem, potongan kode itu harus diambil dan disorot dan seseorang harus dibawa ke samping dan mengatakan, "Lihat, itu kode yang sangat cantik, tetapi mari kita dapatkan DBA untuk membantu Anda membangun kueri terstruktur dengan benar, karena terus terang, itu tidak menyenangkan." Dan URL di sana, Anda dapat pergi dan melihat - itu disebut sebagai query SQL paling kompleks yang pernah Anda tulis. Karena percayalah, itu sebenarnya mengkompilasi, itu berjalan. Dan jika Anda memotong dan menempelnya dan hanya mengejek basis data, itu adalah sesuatu yang perlu diperhatikan; jika Anda punya alat untuk menonton database coba dan lebur selama tiga hingga lima menit, untuk memanggil kembali apa yang merupakan satu baris teks.
Jadi, untuk meringkas, dengan mengingat hal itu, seluruh latar belakang saya dalam pengkodean telah mengajarkan saya bahwa Anda dapat memberi orang senjata dan jika mereka tidak hati-hati mereka akan menembak diri mereka sendiri di kaki; Kuncinya adalah menunjukkan kepada mereka di mana mekanisme keamanan berada. Dengan alat yang tepat dan perangkat lunak yang tepat di ujung jari Anda, setelah Anda melakukan pengkodean, Anda dapat meninjau kode Anda, Anda dapat menemukan masalah dengan membuat profil kode, Anda dapat menemukan bug yang tidak diinginkan secara efektif yang merupakan masalah kinerja, dan seperti yang saya katakan sebelumnya, pada suatu waktu, Anda bisa melakukannya dengan melihat layar hijau. Kamu tidak bisa lagi; ada ratusan ribu baris kode, ada puluhan ribu aplikasi yang digunakan, ada jutaan basis data dalam beberapa kasus, dan bahkan manusia super tidak bisa melakukan ini dengan tangan lagi. Anda benar-benar membutuhkan perangkat lunak yang tepat dan alat yang tepat di ujung jari Anda dan Anda membutuhkan tim untuk menggunakan alat-alat itu, sehingga Anda dapat menemukan masalah ini dan mengatasinya dengan sangat, sangat cepat, sebelum Anda sampai pada intinya, sedangkan Dr. Robin Bloor menyoroti, hal-hal baik menjadi bencana, dan hal-hal meledak, atau lebih umum, mereka baru saja mulai dikenakan biaya banyak dolar dan banyak waktu dan usaha dan menghancurkan moral dan barang-barang, ketika mereka tidak dapat mengetahui mengapa hal-hal mengambil waktu yang lama untuk dijalankan.
Dan dengan itu dalam pikiran, saya akan menyerahkan kepada tamu kami dan saya berharap untuk mendengar bagaimana mereka telah memecahkan masalah ini. Dan khususnya demo yang saya pikir akan kami terima. Eric, aku akan kembali.
Eric Kavanagh: OK, Bert, bawa pergi.
Bert Scalzo: Oke, terima kasih. Bert Scalzo di sini dari IDERA, saya manajer produk untuk alat basis data kami. Dan saya akan berbicara tentang debugging. Saya pikir salah satu hal paling penting yang dikatakan Robin sebelumnya - dan itu sangat benar adalah bahwa debugging itu berat dan non-sepele, dan ketika Anda pergi ke database debugging itu adalah urutan besarnya bahkan lebih berat dan non-sepele - jadi, itu adalah kutipan penting.
BAIK. Saya ingin memulai dengan sejarah pemrograman, karena sering kali saya melihat orang-orang yang tidak melakukan debugging, mereka tidak menggunakan debugger, mereka hanya memprogram dengan bahasa apa pun yang mereka gunakan, dan sering kali mereka akan mengatakan kepada saya, "Ya, hal-hal debugger itu baru, dan kami belum mulai menggunakannya." Jadi yang saya lakukan adalah menunjukkan kepada mereka bagan waktu ini, semacam pra-sejarah, zaman tua, abad pertengahan, itu agak dari katakan di mana kita dalam hal bahasa pemrograman. Dan kami memiliki bahasa yang sangat kuno yang dimulai pada tahun 1951 dengan kode assembly, dan Lisp dan FACT serta COBOL. Kemudian kita masuk ke kelompok berikutnya, Pascals dan Cs dan kemudian kelompok berikutnya, C ++, dan melihat di mana tanda tanya itu - tanda tanya itu kira-kira tepat sekitar tahun 1978 hingga mungkin tahun 1980. Di suatu tempat dalam kisaran itu kami memiliki debuggers tersedia untuk kita, dan untuk mengatakan, "Hei, saya tidak menggunakan debugger, karena itu salah satu dari hal-hal baru, " maka Anda harus sudah mulai pemrograman, Anda tahu, kembali pada 1950-an, karena itulah satu-satunya cara Anda lolos dari klaim itu.
Sekarang hal lain yang lucu tentang bagan ini adalah Dez hanya berkomentar tentang Grace Hopper, saya benar-benar mengenal Grace, jadi agak lucu. Dan kemudian hal lain yang saya tertawakan adalah dia berbicara tentang teletype dan saya duduk di sana berkata, “Bung, itu adalah lompatan terbesar yang pernah kita miliki dalam produktivitas, ketika kita beralih dari kartu ke teletype, itu adalah lompatan terbesar yang pernah ada. "Jadi, dan saya telah memprogram dalam semua bahasa di sini, termasuk SNOBOL, yang belum pernah didengar orang sebelumnya, itu adalah CDC, Control Data Corporation, jadi saya rasa saya sudah agak terlalu tua untuk industri ini .
Dez Blanchfield: Saya akan mengatakan, Anda membuat kami sangat tua di sana.
Bert Scalzo: Ya, saya katakan, saya merasa seperti Kakek Simpson. Jadi saya melihat debugging dan ada berbagai cara melakukan debugging. Anda bisa berbicara tentang apa yang kita semua anggap sebagai tradisional masuk ke debugger dan melangkah melalui kode. Tetapi juga, orang akan memasukkan kode mereka; di situlah Anda memasukkan pernyataan ke dalam kode Anda dan mungkin Anda menghasilkan file output, file jejak atau sesuatu, dan dengan demikian Anda memasukkan kode Anda. Saya akan menghitungnya sebagai debugging, ini sedikit lebih sulit, cara melakukannya, tetapi itu penting. Tapi juga, kita punya pernyataan cetak yang terkenal: Anda menonton dan orang-orang benar-benar memasukkan pernyataan cetak dan saya benar-benar melihat alat di mana - dan itu adalah alat basis data - di mana jika Anda tidak tahu cara menggunakan debugger, Anda menekan tombol dan itu akan menempel pernyataan cetak di seluruh kode Anda untuk Anda dan kemudian ketika Anda selesai Anda menekan tombol lain dan menghapusnya. Karena begitulah cara banyak orang melakukan debug.
Dan alasan kami melakukan debug ada dua: pertama-tama, kami harus menemukan hal-hal yang membuat kode kami tidak efektif. Dengan kata lain, biasanya itu berarti ada kesalahan logika atau kami melewatkan persyaratan bisnis, tetapi apa itu, adalah kode tidak efektif; itu tidak melakukan apa yang kita harapkan. Lain kali kita pergi dan kita melakukan debugging, itu untuk efisiensi dan itu bisa menjadi kesalahan logika, tapi apa itu, adalah aku melakukan hal yang benar, itu tidak kembali dengan cukup cepat. Sekarang, saya menyatakan hal itu karena seorang profiler mungkin lebih baik untuk skenario kedua itu dan kita akan berbicara tentang kedua debugger dan profiler. Selain itu, ada konsep debugging jarak jauh ini; ini penting karena sering kali jika Anda duduk di komputer pribadi, dan Anda menggunakan debugger, yang mengenai database di mana kode sebenarnya dieksekusi pada database, Anda benar-benar melakukan apa yang disebut debugging jarak jauh. Anda mungkin tidak menyadarinya, tetapi itulah yang terjadi. Dan kemudian, sangat umum dengan para penentang ini memiliki titik istirahat, titik tonton, melangkah masuk dan melangkah mundur dan beberapa hal umum lainnya, bahwa saya akan menunjukkannya pada snapshot layar sebentar lagi.
Sekarang, membuat profil: Anda dapat melakukan pembuatan profil dengan beberapa cara berbeda. Beberapa orang akan mengatakan bahwa menangkap beban kerja dan memutar ulang di mana ia menangkap semuanya, yang dianggap sebagai profil. Pengalaman saya lebih baik jika dilakukan sampling. Tidak ada alasan untuk menangkap setiap pernyataan, karena beberapa pernyataan mungkin berjalan begitu cepat sehingga Anda tidak peduli, yang sebenarnya Anda coba lihat adalah, yah, yang merupakan pernyataan yang terus muncul berulang kali, karena mereka berjalan terlalu lama. Jadi, kadang-kadang profiling bisa berarti pengambilan sampel daripada menjalankan semuanya. Dan biasanya, Anda akan mendapatkan beberapa jenis output yang dapat Anda gunakan, sekarang bisa menjadi visual di dalam lingkungan pengembangan IDE, di mana ia dapat memberi Anda seperti histogram kinerja berbagai baris kode, tetapi bisa juga masih baik itu menghasilkan file jejak.
Profiler pertama kali muncul pada tahun 1979. Jadi, mereka sudah ada sejak lama juga. Bagus untuk menemukan konsumsi sumber daya, atau masalah kinerja, dengan kata lain hal efisiensi. Secara umum, ini terpisah dan berbeda dari debugger, walaupun saya telah bekerja dengan para debugger yang melakukan keduanya pada saat yang sama. Dan sementara profiler saya pikir lebih menarik dari dua alat, jika saya merasa bahwa tidak cukup banyak orang men-debug, maka jelas tidak cukup banyak profil orang, karena satu dari sepuluh debugger akan profil, tampaknya. Dan itu memalukan, karena membuat profil benar-benar dapat membuat perbedaan besar. Sekarang, bahasa basis data, seperti yang telah kita bahas sebelumnya, Anda punya SQL - dan kami semacam memaksa pasak bundar ke dalam lubang persegi di sini dan memaksanya untuk menjadi bahasa pemrograman - dan Oracle. Itu PL / SQL - itu bahasa prosedural SQL - dan SQL Server, itu Transact-SQL, itu SQL-99, itu SQL / PSM - untuk, saya pikir, itu Modul Disimpan Prosedur. Postgres memberinya nama lain, DB2 nama lain, Informix, tetapi intinya adalah semua orang telah memaksa konstruksi tipe 3GL; dengan kata lain, UNTUK loop, pada deklarasi variabel dan semua hal lain yang asing ke SQL sekarang menjadi bagian dari SQL dalam bahasa tersebut. Jadi, Anda harus dapat men-debug PL / SQL atau Transact-SQL seperti yang Anda lakukan pada program Visual Basic.
Sekarang, objek basis data, ini penting karena orang-orang akan berkata, “Ya, hal-hal apa yang harus saya debug dalam basis data?” Dan jawabannya adalah, apa pun yang Anda dapat simpan dalam database sebagai kode - jika saya melakukan T-SQL, atau PL / SQL - dan saya menyimpan objek dalam database, ini mungkin merupakan prosedur tersimpan atau fungsi tersimpan. Tetapi ada juga pemicu: pemicu adalah semacam prosedur tersimpan, tetapi memicu beberapa jenis peristiwa. Sekarang, beberapa orang di pemicu mereka akan menempatkan satu baris kode dan memanggil prosedur tersimpan sehingga mereka menyimpan semua kode dan prosedur yang tersimpan, tetapi konsepnya sama: pemicunya masih bisa menjadi yang menginisiasi semuanya. Dan kemudian sebagai Oracle, mereka memiliki sesuatu yang disebut paket, yang seperti perpustakaan jika Anda mau. Anda memasukkan 50 atau 100 prosedur tersimpan ke dalam satu pengelompokan, yang disebut paket, jadi itu seperti perpustakaan. Jadi, inilah debugger dengan cara lama; ini sebenarnya alat yang benar-benar akan masuk dan menempelkan semua pernyataan debug ini dalam kode Anda untuk Anda. Jadi, di mana pun Anda melihat blok debug, jangan hapus, debugger otomatis memulai dan melacak, semua itu terjebak oleh beberapa alat. Dan baris di luar itu, yang merupakan minoritas dari kode, yah, itu metode debugging non-manual.
Dan alasan saya mengemukakan ini adalah, jika Anda mencoba melakukan ini dengan tangan, Anda benar-benar akan mengetik lebih banyak kode debug untuk memasukkan semua pernyataan cetak ini daripada Anda dengan kode. Jadi, sementara ini mungkin bekerja, dan sementara itu lebih baik daripada tidak sama sekali, ini adalah cara yang sangat sulit untuk debug, terutama karena, bagaimana jika dibutuhkan 10 jam untuk menjalankan hal ini, dan di mana ia memiliki masalah ada di baris tiga? Jika saya melakukan sesi debug interaktif, saya akan tahu di baris tiga - lima menit ke dalamnya - hei, ada masalah di sini, saya bisa berhenti. Tetapi dengan ini, saya harus menunggu untuk menjalankannya, semua jalan untuk menyelesaikan dan kemudian saya harus melihat beberapa file jejak yang mungkin memiliki semua pernyataan cetak ini di dalamnya, dan mencoba dan menemukan jarum di tumpukan jerami. Sekali lagi, ini lebih baik daripada tidak sama sekali, tetapi itu bukan cara terbaik untuk bekerja. Sekarang, inilah yang akan terlihat seperti file yang berasal dari slide sebelumnya; dengan kata lain, saya menjalankan program, dan itu hanya punya banyak pernyataan cetak dalam file jejak ini dan saya mungkin atau mungkin tidak dapat menyedot melalui ini dan menemukan apa yang perlu saya temukan. Jadi, sekali lagi, saya tidak begitu yakin bahwa ini adalah cara yang Anda inginkan untuk bekerja.
Sekarang, debuggers interaktif - dan jika Anda menggunakan sesuatu seperti Visual Studio untuk menulis program, atau Eclipse, Anda memiliki debuggers dan Anda menggunakannya dengan bahasa Anda yang lain - hanya saja tidak terpikir untuk menggunakannya di sini dengan database Anda. Dan ada alat di luar sana, seperti DB Artisan dan Rapid SQL kami, ini Rapid SQL di sini, yang memiliki debugger, dan Anda dapat melihat di sisi kiri, saya memiliki prosedur tersimpan yang disebut "periksa duplikat." Pada dasarnya, ini hanya akan pergi dan melihat dan melihat apakah saya memiliki beberapa baris dalam tabel dengan judul film yang sama. Jadi, database untuk film. Dan Anda bisa melihat di sisi kanan, di atas ketiga, saya punya kode sumber saya di tengah, saya punya apa yang disebut variabel arloji saya dan nampan tumpukan panggilan saya, dan kemudian di bagian bawah saya ' Saya punya beberapa pesan keluaran. Dan yang penting di sini adalah, jika Anda melihat panah merah pertama itu, jika saya mengarahkan variabel, saya benar-benar dapat melihat nilai apa yang ada di variabel tersebut pada saat itu, ketika saya sedang menelusuri kode. Dan itu benar-benar berguna, dan kemudian saya dapat melangkah satu baris pada satu waktu melalui kode, saya tidak harus mengatakan eksekusi, saya bisa mengatakan langkah satu baris, biarkan saya melihat apa yang terjadi, langkah baris lain, biarkan saya melihat apa yang terjadi, dan saya melakukan ini di database. Dan walaupun saya menggunakan Rapid SQL di PC saya dan basis data saya ada di cloud, saya masih bisa melakukan debugging jarak jauh dan melihatnya dan mengendalikannya dari sini, dan melakukan debugging seperti yang saya lakukan dengan bahasa lain.
Sekarang, panah berikutnya di sana - Anda dapat melihat panah kecil seperti menunjuk ke kanan, menuju output DBMS, di situlah kursor saya saat ini - jadi dengan kata lain, saya telah melangkah dan di sanalah saya berada di saat ini. Jadi, jika saya berkata, "Langkah lagi, " saya akan pergi ke baris berikutnya. Sekarang tepat di bawah Anda akan melihat titik merah. Nah, itu breakpoint, yang mengatakan "Hei, aku tidak ingin melangkahi garis-garis ini." Jika aku hanya ingin melompati semuanya dan sampai ke titik merah itu, aku dapat menekan tombol run dan itu akan berjalan dari sini hingga akhir, atau ke breakpoint, jika ada breakpoint yang ditetapkan, dan kemudian akan berhenti dan biarkan saya melakukan stepping lagi. Dan alasan mengapa ini penting dan kuat adalah, karena ketika saya melakukan semua ini, apa yang terjadi di tengah dan bahkan di bawah - tetapi yang paling penting di tengah - akan berubah dan saya bisa melihat nilai dari variabel saya, Saya dapat melihat jejak tumpukan panggilan saya, Anda tahu, dan semua informasi itu ditampilkan di sana saat saya sedang menelusuri kode, jadi saya benar-benar dapat melihat dan merasakan serta mendapatkan pemahaman tentang apa yang terjadi dan bagaimana kode sebenarnya. bekerja pada waktu eksekusi. Dan biasanya saya dapat menemukan masalah, jika ada, atau jika saya cukup baik untuk menangkapnya.
OK, sekarang saya akan berbicara tentang profiler, dan dalam hal ini, ini adalah profiler yang dapat saya lihat melalui debugger. Ingat saya katakan kadang-kadang mereka terpisah dan kadang-kadang mereka bisa bersama? Dalam hal ini, dan sekali lagi, saya menggunakan Rapid SQL, dan saya dapat melihat ada margin, di sebelah kiri, di sebelah nomor baris. Dan apa itu, adalah itu jumlah detik atau mikrodetik yang diperlukan untuk mengeksekusi setiap baris kode, dan saya dapat melihat dengan jelas, semua waktu saya dihabiskan dalam satu ini UNTUK loop di mana saya memilih semuanya dari sebuah tabel . Jadi, apa pun yang terjadi di dalam lingkaran FOR itu mungkin adalah sesuatu yang perlu saya perhatikan, dan jika saya bisa membuatnya lebih baik, itu akan membayar dividen. Saya tidak akan mendapatkan perbaikan apa pun dengan mengerjakan garis yang memiliki seperti 0, 90 atau 0, 86; tidak banyak waktu yang dihabiskan di sana. Sekarang, dalam hal ini, dan sekali lagi, saya menggunakan Rapid SQL, Anda melihat bagaimana saya dapat melakukan profiling yang dicampur dengan debugging saya. Sekarang, yang bagus adalah Rapid SQL juga memungkinkan Anda melakukannya dengan cara lain. SQL cepat memungkinkan Anda untuk mengatakan, “Anda tahu apa? Saya tidak ingin berada di debugger, saya hanya ingin menjalankan ini dan kemudian saya ingin melihat secara grafis atau secara visual jenis informasi yang sama. "
Dan Anda dapat melihat bahwa saya tidak lagi di debugger dan menjalankan program dan setelah eksekusi selesai, itu memberi saya bagan untuk memberi tahu saya hal-hal sehingga saya dapat melihat bahwa saya punya satu pernyataan yang sepertinya mengambil sebagian besar diagram lingkaran dan jika saya melihat, saya melihat pada grid itu ke arah bawah, baris 23, ada loop FOR lagi: dia mengambil paling banyak waktu, dia sebenarnya merah tua mengunyah semua diagram lingkaran. Jadi, ini adalah cara lain untuk melakukan profil. Kami kebetulan menyebutnya "Analis Kode" di alat kami. Tapi itu pada dasarnya hanya profiler yang terpisah dari debugger. Beberapa orang suka melakukannya dengan cara pertama, beberapa orang suka melakukannya dengan cara kedua.
Mengapa kita melakukan debugging dan profil? Itu bukan karena kami ingin menulis kode terhebat di dunia dan mendapat kenaikan gaji - itu mungkin alasan kami, tapi itu bukan alasan Anda melakukannya - Anda berjanji pada bisnis Anda akan melakukan sesuatu dengan benar, bahwa program Anda akan efektif. Untuk itulah Anda akan menggunakan debugger. Selain itu, pengguna akhir bisnis; mereka tidak terlalu sabar: mereka menginginkan hasil bahkan sebelum mereka menekan tombol. Kita seharusnya membaca pikiran mereka dan melakukan semuanya secara instan. Dengan kata lain, itu harus efisien. Jadi, itulah yang akan kami gunakan untuk profiler. Sekarang, tanpa alat-alat ini, saya benar-benar percaya Anda adalah orang ini dalam setelan bisnis dengan busur dan anak panah dan Anda menembak target dan Anda ditutup matanya. Karena bagaimana Anda akan menemukan bagaimana suatu program dijalankan dengan hanya melihat kode statis dan bagaimana Anda akan mencari tahu baris mana yang paling menghabiskan waktu dalam eksekusi, sekali lagi, hanya dengan melihat kode statis? Peninjauan kode mungkin atau mungkin tidak memunculkan beberapa hal ini, tetapi tidak ada jaminan peninjauan kode akan menemukan semuanya. Menggunakan debugger dan profiler Anda harus dapat menemukan semua bug itu.
OK, saya hanya akan melakukan demo cepat di sini. Bukan maksud saya untuk mendorong produk, saya hanya ingin menunjukkan kepada Anda seperti apa bentuk debugger karena sering kali orang berkata, "Saya belum pernah melihat yang seperti ini sebelumnya." Dan itu terlihat cantik di slide layar., tapi seperti apa saat bergerak? Jadi, di sini di layar saya, saya menjalankan produk DB Artisan kami; kami memiliki debugger di sana juga. DB Artisan lebih berarti untuk DBA, Rapid SQL lebih untuk para pengembang, tetapi saya telah melihat pengembang yang menggunakan DB Artisan, dan saya telah melihat DBA yang menggunakan Rapid. Jadi, jangan terjebak pada produk. Dan di sini, saya memiliki pilihan untuk melakukan debug, tetapi sebelum saya meluncurkan debug, saya akan mengekstrak kode ini sehingga Anda dapat melihat seperti apa kode itu sebelum saya mulai menjalankannya. Jadi, inilah kode yang persis sama dengan yang ada di snapshot layar, ini adalah cek saya untuk duplikat. Dan saya ingin men-debug ini, jadi saya tekan debug. Dan sekarang, perlu beberapa saat dan Anda berkata, “Ya, mengapa perlu waktu?” Ingat debugging jarak jauh: debugging sebenarnya terjadi di server database saya, bukan di PC saya. Jadi, itu harus pergi dan membuat sesi di sana, membuat hal debugging jarak jauh, kaitkan sesi saya ke sesi debugging jarak jauh dan mengatur saluran komunikasi.
Jadi, sekarang, ini panah saya, di atas sana, di atas, dengan baris pertama, di situlah saya berada di dalam kode. Dan jika saya menekan ikon ketiga di sana, yang merupakan langkah maju, Anda akan melihat panah itu baru saja bergerak, dan jika saya terus menekannya, Anda akan melihatnya terus bergerak. Sekarang, jika saya ingin pergi jauh ke loop FOR ini, karena saya tahu di situlah masalahnya, saya dapat menetapkan breakpoint. Saya pikir saya yang mengaturnya. Oh menembak, saya punya salah satu kunci screen capture saya dipetakan ke tombol yang sama dengan debugger, itulah yang menyebabkan kebingungan. OK, jadi saya hanya mengatur breakpoint secara manual di sana, jadi sekarang daripada melakukan langkah, langkah, langkah, langkah sampai saya tiba di sana, sebenarnya saya hanya bisa mengatakan, "Silakan jalankan hal ini, " dan itu akan berhenti. Perhatikan itu menggerakkan saya sampai ke tempat break point, jadi saya sekarang ke dalam konteks menjalankan loop ini, saya bisa melihat semua variabel saya diatur, yang tidak mengejutkan, karena saya menginisialisasi mereka semua ke nol. Dan sekarang, saya bisa masuk ke loop ini dan mulai melihat apa yang terjadi di dalam loop ini.
Jadi, sekarang ia akan melakukan penghitungan pilih dari persewaan saya dan saya bisa mengarahkan mouse ke orang itu dan lihat, dia dua, dua lebih besar dari satu, jadi mungkin akan melakukan bagian selanjutnya dari kode ini. Dengan kata lain, ia menemukan sesuatu. Saya hanya akan pergi ke depan dan membiarkan itu berjalan. Saya tidak ingin melewati semuanya di sini; apa yang ingin saya tunjukkan adalah ketika debugger selesai, itu selesai seperti program normal. Saya memiliki set breakpoint, jadi ketika saya mengatakan jalankan, itu hanya kembali ke breakpoint berikutnya. Saya membiarkannya berjalan sampai akhir, karena apa yang saya ingin Anda lihat adalah bahwa debugger tidak mengubah perilaku program: ketika selesai dijalankan, saya harus mendapatkan hasil yang sama persis jika saya menjalankannya tidak di dalam debugger.
Dan dengan itu, saya akan menangguhkan demo dan kembali karena kami ingin memastikan kami punya waktu untuk pertanyaan dan jawaban. Jadi, saya akan membukanya untuk pertanyaan dan jawaban.
Eric Kavanagh: Baiklah, Robin, mungkin pertanyaan dari Anda dan kemudian pasangan dari Dez?
Robin Bloor: Ya, tentu saja, saya menemukan ini menarik, tentu saja. Saya telah bekerja dengan hal-hal seperti ini, tetapi saya tidak pernah bekerja dengan hal seperti ini di database. Bisakah Anda memberi saya ide tentang apa yang digunakan orang untuk profiler? Karena itu seperti, apakah mereka melihat - karena saya kira mereka - mereka sedang melihat masalah kinerja, apakah itu akan membantu Anda membedakan antara kapan database membutuhkan waktu dan kapan kode membutuhkan waktu?
Bert Scalzo: Anda tahu, itu pertanyaan yang fantastis. Katakanlah saya bekerja di Visual Basic, dan saya, di dalam Visual Basic saya, saya akan memanggil Transact-SQL atau PL / SQL. Biarkan saya melakukan PL / SQL, karena Oracle tidak bermain dengan baik selalu dengan alat Microsoft. Saya mungkin memrofilkan kode Visual Basic saya, dan profil di sana mungkin berkata, "Hei, saya menyebut prosedur tersimpan ini dan butuh waktu terlalu lama." Tapi kemudian saya bisa masuk ke prosedur tersimpan dan saya bisa melakukan profil basis data pada penyimpanan tersebut. prosedur dan berkata, "Oke, dari 100 pernyataan yang ada di sini, inilah lima yang menyebabkan masalah." Jadi, Anda mungkin harus membuat tim tag, di mana Anda harus menggunakan beberapa profiler.
Idenya adalah jika Anda pernah diberitahu masalah kinerja ada di database Anda, profil database dapat membantu Anda menemukan jarum di tumpukan jerami di mana pernyataan sebenarnya yang mana Anda memiliki masalah. Saya memberi tahu Anda hal lain yang muncul dengan membuat profil: jika Anda memiliki kode yang disebut jutaan kali, tetapi hanya membutuhkan satu mikrodetik setiap juta kali, tetapi dipanggil jutaan kali, apa yang akan ditampilkan oleh profiler, benda itu berlari selama banyak unit waktu ini. Jadi, sementara kodenya mungkin sangat efisien, Anda mungkin melihat dan berkata, “Ooh, kami terlalu sering membuat panggilan ke bagian kode ini. Mungkin kita seharusnya hanya menyebutnya begitu sering, daripada setiap kali kita memproses catatan, ”atau sesuatu. Jadi Anda benar-benar dapat menemukan di mana ada kode efisien yang baru saja dipanggil terlalu sering, dan itu sebenarnya masalah kinerja.
Robin Bloor: Ya, itu luar biasa. Saya belum pernah melakukan ini. Anda tahu, tentu saja, ketika saya memiliki masalah basis data, rasanya seperti saya akan berurusan dengan basis data atau berurusan dengan kode; Saya tidak pernah bisa berurusan dengan mereka berdua secara bersamaan. Tetapi di sana, sekali lagi, saya tidak melakukan- Saya tidak pernah benar-benar terlibat dalam membangun aplikasi tempat kami menyimpan prosedur, jadi saya kira saya tidak pernah benar-benar mengalami masalah yang dulu membuat saya liar, gagasan bahwa Anda akan membagi kode antara database dan program. Tetapi, lakukan semua- Saya kira jawabannya adalah ya, tetapi ini adalah bagian dari kegiatan tim pengembangan, ketika Anda sedang berusaha memperbaiki sesuatu yang rusak, atau mungkin mencoba membawa yang baru aplikasi bersama. Tetapi apakah ini semua sesuai dengan semua komponen lain yang saya harapkan di lingkungan? Dapatkah saya berharap bahwa saya dapat menggabungkan semua ini dengan semua paket pengujian saya dan semua hal lain yang akan saya lakukan dan dengan hal-hal manajemen proyek saya, apakah itu bagaimana semua klip ini disatukan?
Bert Scalzo: Ya, itu bisa menjadi bagian dari proses terstruktur untuk melakukan pemrograman atau upaya pengembangan Anda. Dan itu lucu, minggu lalu saya punya pelanggan yang sedang membangun aplikasi web, dan database mereka kecil, secara historis, dan fakta bahwa mereka bukan programmer yang baik tidak pernah menyakiti mereka. Nah, basis data mereka telah berkembang selama bertahun-tahun, dan sekarang dibutuhkan 20 detik di halaman web, di antara saat Anda berkata, "Log in dan beri saya beberapa data untuk dilihat" dan ketika layar benar-benar muncul, dan jadi sekarang ini masalah kinerja. Dan mereka tahu masalahnya bukan di Jawa atau di tempat lain mana pun. Tetapi mereka memiliki ribuan prosedur tersimpan sehingga mereka harus mulai membuat profil prosedur tersimpan untuk mencari tahu mengapa halaman web ini membutuhkan waktu 20 detik untuk muncul? Dan kami benar-benar mendapati mereka memiliki Cartesian yang bergabung dalam salah satu pernyataan pilihan mereka dan tidak mengetahuinya.
Robin Bloor: Wow.
Bert Scalzo: Tetapi seseorang berkata kepada saya suatu kali, "Bagaimana mereka bisa membuat seorang Cartesian bergabung dan tidak mengetahuinya?" Dan ini akan terdengar sangat mengerikan; kadang-kadang seorang programmer yang tidak terlalu nyaman dengan SQL akan melakukan sesuatu seperti memberi saya bergabung Cartesian, tetapi kemudian hanya memberi saya kembali catatan pertama, jadi saya tahu saya punya sesuatu, dan saya hanya perlu yang pertama. Jadi, mereka tidak menyadari bahwa mereka baru saja mengembalikan satu miliar catatan atau mereka melihat satu miliar catatan, karena mereka mendapatkan yang mereka sukai.
Robin Bloor: Wow, saya tahu, itulah yang disebut - yah, itulah yang sedang terjadi tentang Dez, dalam hal orang-orang yang tidak begitu terampil seperti yang seharusnya, Anda tahu. Jika Anda seorang programmer, Anda harus tahu apa implikasi dari mengeluarkan perintah apa pun. Maksudku, sungguh, tidak ada alasan tingkat kebodohan itu. Saya juga berasumsi bahwa Anda, dalam satu atau lain cara, hanya agnostik bahasa dalam hal ini, karena ini semua berfokus pada sisi database. Apakah saya benar dalam hal itu? Apakah sama saja, apa pun yang Anda gunakan di sisi pengkodean?
Bert Scalzo: Tentu saja, Anda dapat melakukan ini di Fortran atau C atau C ++. Bahkan, pada beberapa Unix Anda bahkan dapat melakukannya untuk bahasa scripting mereka; mereka sebenarnya menyediakan alat yang sama. Dan kemudian saya ingin kembali sejenak untuk apa yang Anda katakan tanpa alasan. Saya akan memberi para programmer istirahat, karena saya tidak suka melemparkan programmer di bawah bus. Tetapi masalahnya sebenarnya adalah lingkungan akademik karena ketika Anda pergi untuk belajar bagaimana menjadi seorang programmer, Anda diajarkan cara berpikir yang cepat. Anda tidak diajari set thinking, dan itulah yang Structured Query Language, atau SQL bekerja dengan set; itu sebabnya kami memiliki serikat pekerja, persimpangan dan operator minus. Dan kadang-kadang sangat sulit bagi seseorang yang tidak pernah berpikir dalam hal set, untuk berhenti, melepaskan pemrosesan rekor pada suatu waktu dan bekerja dengan set.
Robin Bloor: Ya, saya ikut dengan Anda dalam hal itu. Maksudku, aku mengerti sekarang, itu masalah pendidikan; Saya pikir itu sepenuhnya masalah pendidikan, saya pikir itu wajar bagi programmer untuk berpikir secara prosedural. Dan SQL tidak prosedural, ini deklaratif. Anda sebenarnya hanya mengatakan, "Ini yang saya inginkan dan saya tidak peduli bagaimana Anda melakukannya, " Anda tahu? Sedangkan dengan bahasa pemrograman Anda sering mendapatkan lengan baju Anda digulung dan Anda turun ke dalam hal-hal kecil bahkan mengelola hitungan, saat Anda melakukan loop. Saya akan menyerahkan ke-
Bert Scalzo: Tidak. OK, lanjutkan.
Ya, saya akan mengatakan Anda mengemukakan satu contoh lain bahwa seorang profiler akan baik menangkap, semacam melanjutkan dengan pemrosesan catatan-pada-waktu-ini. Kadang-kadang, seorang programmer yang pandai dalam catatan logika, tidak tahu bagaimana melakukan program SQL. Nah, katakanlah dia membuat dua loop UNTUK dan pada dasarnya bergabung, tetapi dia melakukannya di sisi klien. Jadi, dia melakukan efek yang sama dengan bergabung, tetapi dia melakukannya sendiri, dan profil akan menangkapnya, karena Anda mungkin akan menghabiskan lebih banyak waktu melakukan bergabung secara manual daripada membiarkan server database melakukannya untuk Anda.
Robin Bloor: Ya, itu akan menjadi bencana. Maksudku, kau hanya akan meronta-ronta. Thrashing selalu buruk.
Bagaimanapun, saya akan meneruskan ke Dez; Saya yakin dia punya beberapa pertanyaan menarik.
Dez Blanchfield: Terima kasih, ya, saya tahu. Saya akan bergabung dengan Anda di programer tidak melemparkan di bawah bus. Maksud saya, saya telah menghabiskan waktu bertahun-tahun dalam hidup saya sendiri sebagai seorang pembuat kode, pada setiap level, Anda tahu, apakah itu seperti yang Anda katakan, duduk di baris perintah mesin Unix, dan dalam beberapa kasus, saya bahkan terlibat dalam beberapa port berbeda Unix dari satu platform perangkat keras ke yang lain. Dan Anda dapat membayangkan tantangan yang kami alami di sana. Tetapi kenyataannya adalah inilah kartu keluar-penjara untuk setiap pembuat kode dan penulis skenario di dunia. Ini adalah ilmu roket, secara harfiah, untuk menulis sangat ketat setiap saat, sepanjang waktu, adalah ilmu roket. Dan kisah-kisah terkenal dari orang-orang seperti Dennis Ritchie dan Brian Kernahan mengerjakan beberapa kode secara mandiri dan kemudian beralih ke obrolan ulasan kode sambil minum kopi dan mengetahui mereka telah menulis kode yang persis sama, dalam program yang persis sama, dengan cara yang persis sama. Dan mereka melakukannya di C. Tetapi pemrograman tingkat purist itu sangat jarang ada.
Faktanya adalah bahwa setiap hari, hanya ada 24 jam sehari, tujuh hari seminggu, dan kita hanya harus menyelesaikan pekerjaan. Jadi, ketika datang ke tidak hanya programmer tradisional, DBA, dan coders, dan skrip, dan sysadmin, dan admin jaringan, dan staf keamanan, dan semuanya sampai ke sisi data warga hari ini; kami dengar, semua orang hanya berusaha melakukan pekerjaan mereka. Jadi saya pikir takeaway hebat dari semua ini adalah saya menyukai demo Anda dan saya suka takeaway yang Anda tinggalkan di sana, beberapa saat yang lalu, berbicara dengan Robin tentang fakta bahwa ini memang memiliki yang khusus - mungkin tidak begitu banyak sebuah ceruk - tetapi ruang yang luas untuk itu, sejauh memperbaiki kode dan SQL dan basis data. Tetapi saya sangat senang mendengar Anda mengatakan bahwa Anda dapat menyodoknya pada skrip shell dan menemukan beberapa masalah, karena Anda tahu, di zaman sekarang ini kita selalu berupaya dengan biaya terendah dalam segala hal.
Alasan Anda dapat membeli baju seharga $ 6 di suatu tempat, adalah karena seseorang membuat sistem yang cukup murah untuk benar-benar memproduksi dan mengirimkan serta secara logis mengirimkan dan menjual dan menjual serta mengambil pembayaran online untuk mendapatkan baju seharga $ 6 itu. Dan itu tidak terjadi jika Anda membuat orang dibayar $ 400.000 setahun untuk menulis kode dengan cara yang sempurna; itu hanya pengembangan keseluruhan. Jadi, saat itu, saya kira salah satu pertanyaan yang saya benar-benar ingin Anda berikan kepada kami lebih banyak wawasan, adalah seberapa luas dan jangkauan tipe orang yang Anda lihat saat ini yang menggunakan alat-alat semacam ini untuk diprofilkan kode dan mencari masalah kinerja? Awalnya, secara historis, dari mana mereka berasal? Apakah mereka rumah rekayasa besar? Dan kemudian, ke depan, apakah ini masalahnya, apakah saya benar dalam berpikir bahwa semakin banyak perusahaan yang mengimplementasikan alat ini, atau alat-alat ini, untuk mencoba dan membantu pembuat kode, yang mereka tahu yang baru saja menyelesaikan pekerjaan untuk menyelesaikan pekerjaan dan mengeluarkannya dari pintu? Dan kadang-kadang kita membutuhkan kartu keluar dari penjara? Apakah saya benar dalam berpikir bahwa secara historis kami memiliki lebih banyak fokus dan pengembangan teknik? Bahwa sekarang, kita semakin kurang, seperti yang dikatakan Robin, pendekatan akademis, dan sekarang kode otodidak, atau cut-and-paste, atau hanya membangun sesuatu? Dan apakah itu cocok dengan jenis orang yang menggunakan produk sekarang?
Bert Scalzo: Ya, persis. Dan saya akan memberi Anda contoh yang sangat spesifik, kami hanya ingin menyelesaikan pekerjaan, karena para pebisnis tidak menginginkan kesempurnaan. Ini seperti permainan catur yang terkomputerisasi: permainan catur tidak mencari jawaban yang sempurna; mencari jawaban yang cukup baik dalam jumlah waktu yang wajar, jadi itulah cara kami memprogram. Tapi yang saya temukan sekarang adalah, kebanyakan orang bukannya mengatakan mereka menginginkan profiler sebagai bagian dari pengujian unit mereka - itulah cara saya akan melakukannya, karena saya tidak melihatnya sebagai pemborosan waktu - yang terjadi adalah sekarang itu dilakukan nanti, kadang-kadang, selama pengujian integrasi atau pengujian stres, jika kita beruntung. Tetapi sebagian besar waktu itu merupakan bagian dari eskalasi, di mana ada sesuatu yang diproduksi, itu berjalan untuk sementara waktu, mungkin bahkan berjalan selama bertahun-tahun, dan sekarang itu tidak berjalan dengan baik, dan sekarang kita akan memprofilkannya. Dan itu tampaknya menjadi skenario yang lebih umum sekarang.
Dez Blanchfield: Ya, dan saya pikir istilah "utang teknis" mungkin salah satu yang lebih Anda kenal; Saya tahu Robin dan tentu saja saya. Saya pikir hari ini, terutama dalam pendekatan tangkas untuk pengembangan dan pembangunan sistem, bagi saya, konsep utang teknis sekarang adalah hal yang sangat nyata, dan kami benar-benar memperhitungkannya dalam proyek. Saya tahu, maksud saya, kami memiliki proyek kami sendiri seperti Media Lens dan lainnya, di mana kami memiliki pengkodean yang terjadi setiap hari, dan berbagai hal di seluruh Grup Bloor. Dan setiap kali kita membangun sesuatu, kita melihat, saya melihatnya, dan selalu melihat dari sudut pandang berapa biayanya untuk memperbaiki ini sekarang, dibandingkan bisakah saya mendapatkannya di bisa dan keluarkan di sana, lalu perhatikan dan lihat apakah benda ini akan pecah. Dan mewarisi hutang teknis ini yang saya tahu saya harus memutar kembali nanti dan memperbaikinya.
Dan maksud saya, saya telah melakukan itu dalam tujuh hari terakhir: Saya telah menulis beberapa alat dan skrip, saya telah menulis beberapa bagian dari bahasa Python, dan saya telah menyebarkannya ke Mongo dari belakang, membuat yakin itu bagus dan bersih dan aman, tetapi hanya mendapatkan kueri yang perlu saya lakukan, mengetahui bahwa saya membutuhkan fungsi itu untuk bekerja, untuk sampai ke teka-teki yang lebih besar; di situlah rasa sakit saya yang sebenarnya. Jadi Anda menanggung hutang teknis ini, dan saya pikir ini sekarang bukan hanya hal yang sesekali, saya pikir ini adalah bagian dari DNA yang sedang berkembang sekarang. Orang hanya - tidak jujur - mereka hanya menerima utang teknis adalah jenis modus modus operandi yang normal, dan mereka hanya harus menanggungnya. Di sinilah Anda menanggung hutang teknis. Dan saya pikir hal hebat tentang apa yang Anda perlihatkan kepada kami di demo adalah Anda benar-benar dapat membuat profil dan menonton berapa lama waktu yang dibutuhkan untuk menjalankan. Dan itu mungkin salah satu hal favorit saya. Maksud saya, saya benar-benar membuat alat profil - kami dulu membangun alat di Sed dan Lex dan Orc untuk menjalankan kode kami dan melihat di mana loopnya, sebelum alat seperti ini tersedia - dan ketika Anda membuat kode untuk pergi dan Tinjau kode Anda sendiri, Anda menjadi sangat baik karena tidak harus meninjau kode Anda sendiri. Tapi bukan itu masalahnya sekarang. Dengan pemikiran itu, apakah ada segmen pasar tertentu yang mengambil alih ini lebih dari yang lain? Melihat seperti massa-
Bert Scalzo: Oh ya, saya punya- Saya akan menggambar analogi untuk Anda, dan menunjukkan kepada Anda bahwa bukan pemrogram melakukannya sepanjang waktu. Karena jika saya pernah mengajar kelas atau sesi debugger dan profiling, saya akan bertanya kepada orang-orang, "Oke, berapa banyak orang di sini yang masuk ke Microsoft Word dan sengaja tidak pernah menggunakan pemeriksa ejaan?" Dan tidak ada yang mengangkat tangan mereka, karena untuk menulis dokumen, kita semua tahu kita bisa membuat kesalahan bahasa Inggris, dan semua orang menggunakan pemeriksa ejaan. Dan saya berkata, “Baiklah, bagaimana jika Anda menulis teks dalam IDE Anda seperti Visual Basic, Anda tidak menggunakan debugger? Itu adalah hal yang sama, itu seperti pemeriksa ejaan. ”
Dez Blanchfield: Ya, sebenarnya, itu analogi yang bagus. Saya tidak benar-benar memikirkan, saya harus mengakui bahwa saya benar-benar melakukan sesuatu yang mirip dengan beberapa alat yang saya gunakan. Bahkan, satu, ODF, favorit saya dengan Eclipse hanya memotong dan menempelkan kode di sana dan pergi mencari hal-hal yang langsung disorot dan menyadari saya membuat kesalahan ketik dalam beberapa panggilan kelas. Dan, tetapi menarik sekarang dengan alat seperti ini Anda dapat melakukannya secara waktu nyata sebagai lawan untuk kembali dan melihatnya nanti, yang agak menyenangkan untuk ditangkap di muka. Tapi ya, itu analogi yang bagus dari hanya menempatkan teks ke dalam pengolah kata, karena itu adalah panggilan bangun yang menarik, hanya menyadari bahwa Anda telah membuat kesalahan ketik atau bahkan kesalahan tata bahasa, kan?
Bert Scalzo: Tepat.
Dez Blanchfield: Jadi, apakah Anda melihat lebih banyak uptick sekarang dari saya kira, maksud saya, pertanyaan terakhir dari saya, sebelum saya melemparkan ke Q&A kami mungkin, untuk peserta kami. Jika Anda akan memberikan semacam rekomendasi seputar pendekatan untuk melakukan ini - saya berasumsi ini retoris - apakah ini kasus yang Anda dapatkan lebih awal dan menerapkan ini saat Anda sedang berkembang, sebelum Anda berkembang? Atau itu adalah kasus dimana Anda sebagian besar membangun, bergerak, membangun sesuatu kemudian masuk dan membuat profil nanti? Saya menduga ini adalah kasus awal dan pastikan kode Anda bersih di muka. Atau apakah mereka harus mempertimbangkan ini bagian dari penempatan mereka?
Bert Scalzo: Idealnya, mereka akan melakukannya di muka, tetapi karena semua orang berada di dunia yang sibuk, di mana mereka baru saja menyelesaikan pekerjaan, mereka cenderung tidak melakukannya sampai mereka mengalami masalah kinerja yang tidak dapat mereka selesaikan dengan menambahkan lebih banyak CPU dan memori ke mesin virtual.
Dez Blanchfield: Ya. Jadi, sebenarnya Anda menyebutkan sesuatu yang menarik, apakah saya bisa cepat? Anda sebutkan sebelumnya bahwa ini dapat dijalankan dari mana saja, dan dapat berbicara dengan database di bagian belakang. Jadi ini nyaman dengan jenis konsep bimodal yang kita bicarakan sekarang, tentang on-premise / off-premise cloud, dari segi berbagai hal, pada akhirnya, jika ia dapat berbicara dari belakang dan melihat kodenya, tidak peduli, kan?
Bert Scalzo: Tepat, ya, Anda dapat menjalankan ini di cloud.
Dez Blanchfield: Luar biasa, karena saya pikir di situlah dunia pemberani baru kita akan pergi. Jadi, Eric. Saya akan melemparkan kembali kepada Anda sekarang dan melihat bahwa kami punya beberapa pertanyaan di sini dan saya ingin peserta kami tetap tinggal bersama kami, meskipun kami sudah melewati jam.
Eric Kavanagh: Ya, ada beberapa orang di luar sana, saya hanya akan membuat komentar singkat: Bert, saya pikir metafora itu, analogi yang Anda berikan menggunakan spell check sangat terang. Itu layak untuk satu atau dua blog, terus terang, karena ini adalah cara yang baik untuk membingkai konteks apa yang Anda lakukan, dan betapa berharganya itu, dan bagaimana itu benar-benar harus menjadi praktik terbaik untuk menggunakan debugger secara teratur, bukan? Saya yakin Anda mendapatkan beberapa kepala mengangguk ketika Anda membuang itu, kan?
Bert Scalzo: Tentu saja, karena apa yang saya katakan kepada mereka adalah, “Mengapa saya menjalankan pemeriksaan ejaan pada dokumen saya? Saya tidak ingin malu dengan kesalahan pengejaan yang bodoh. ”Yah, mereka tidak mau malu dengan kesalahan pengodean yang bodoh!
Eric Kavanagh: Benar. Ya memang. Baiklah, teman-teman, kami telah membakar selama satu jam lima menit di sini, terima kasih banyak untuk Anda semua di luar sana atas waktu dan perhatian Anda. Kami mengarsipkan semua obrolan web ini, jangan ragu untuk kembali kapan saja dan memeriksanya. Tempat terbaik untuk menemukan tautan itu mungkin techopedia.com, jadi kami akan menambahkannya ke daftar ini di sini.
Dan dengan itu, kami akan mengucapkan selamat tinggal, kawan. Sekali lagi, kerja bagus, Bert, terima kasih kepada teman-teman kami dari IDERA. Kami akan berbicara dengan Anda lain kali, kami akan berbicara dengan Anda minggu depan, sebenarnya. Hati hati! Sampai jumpa.
