Content provided by Voice of the DBA. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Voice of the DBA or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Player FM - Podcast App Go offline with the Player FM app!
Riddles, troikas, and food references abound! After a forbidden scroll is removed from the Arcane Library from the city of Eltin, a ragtag group of adventurers is dispatched to track it down. Join our party on their mysterious adventure, as Melony Melons tries to make friends, Agent Peaches searches for his next big story, Fromage passes some hot cheese samples to anyone who will listen, and Metzger Abbatoir tries to convince everyone he isn’t his father’s son. Starring: Nathan Zimmerer - Melony Melons Kyle Kane - Agent Peaches Shea Ingram - Metzger Abbatoir AKA Bouchet Chris Arr - Fromage Josh Greenway - The Dungeon Newbie Based on the Unraveled one-shot from Roll & Play Press https://rollandplaypress.com Edited by Josh Greenway Sound Effects provided by Pixabay.com Music Josh Greenway & Mark Canning Clavier Clavier https://pixabay.com/users/clavier-music-16027823 Kellepics Https://pixabay.com/users/kellepics-4893063…
Content provided by Voice of the DBA. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Voice of the DBA or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Content provided by Voice of the DBA. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Voice of the DBA or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
I had to make a few changes to a SQL Saturday event recently. The repo is public , and some of the organizers submit PRs for their changes, and others send me an email/message/text/etc. for a change. In this case, an organizer just asked for a couple of image updates to their site. I opened VS Code, created a branch, added a URL for the images, and submitted my own PR. After the build, I deployed it. And it didn’t work. I had a broken image. I checked the URL in code and realized I had “events” copied before the URL, which wasn’t valid. Ok, edit the URL to be correct and repeat: new PR, build, merge, deploy. And it didn’t work. I was looking at the code live on the site, the code in the repo, and I was trying to reconcile paths and file names and keys and values and a few other things. I realized the world for a developer hadn’t changed a lot, and in fact, I was in the age-old loop: deploy, patch, patch the patch, fix the patch for the patch, and so on. I don’t even know that I could have gotten better here with testing, as these were one-off data changes that affected the site for users. If I enter the wrong data, it’s wrong. I can’t easily test for this. I have written code that was wrong, and a few simple tests would have caught my issues. I’ve also written code that isn’t easy to test. If I am adding or changing data, it’s hard to test that. Often, I might do some copy/pasting between the code and the test to generate the test. If I’ve typoed something, the typo continues through the test (in some cases). Even using a code generator or an AI to produce the INSERT or UPDATE code might not solve the problem. They might read my typos in a prompt. One of the best things to help code quality in the last few decades is continuous integration (CI), where we have automated systems that compile code, test it, and run it. It’s not perfect, but it does help reduce the silly mistakes many of us likely make every day when writing code. These can’t prevent typos and issues, but if we are testing intermediate systems, hopefully somewhere along the way, a human or AI agent tries to verify that the things we were typing exist and can catch a typo. In this case, I had to find where I’d mistyped the line and realized that I had the path wrong. The image was in a subfolder and I needed to add that to the img url. Working with data is hard, and it’s a constant source of simple mistakes. I don’t know we’ll ever get away from patching the patch when data manipulation is involved. Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…
When talking about DevOps, the goal is to produce better software over time. Both better quality as well as a smoother process of getting bits to your clients. There are a number of metrics typically used to measure how well a software team is performing, and one of the things is Change fail percentage. This is the percentage of deployments that causes a failure in production, which means a hotfix or rollback is needed. Essentially we need to fail forward or roll back to get things working. For most people, a failed deployment means downtime. I’ve caused a service to be down (or a page or an app) because of a code change I made. This includes the database, as a schema change could cause the application to fail. Maybe we’ve renamed something (always a bad idea) and the app hasn’t updated. Maybe we added a new column to a table and some other code has an insert statement without a column list that won’t run. There are any number of database changes that might require a hotfix or rollback and could be considered a failure. However, some people see an expanded definition. If a service is degraded (slower), is that a failure? Some people think so. If we change code in a database (or indexes) and see performance slow down. In that case, is this a failed deployment? Customers would think so. Developers might not like this idea, at least not without some sort of SLA that might allow for some things to be a little slower. After all, slow is still working, right? What if I don’t notice a problem? Imagine I add a new table/column, and the app starts accepting data and storing it. What if we are supposed to use this data downstream, and we don’t notice it is being aggregated incorrectly by a process until many days later. Perhaps we’ve performed some manipulation or calculation on our data and the result isn’t what we wanted. It might not be incorrect, but maybe it’s ignoring NULLs when we want NULLs treated as 0s. Is that a failure? If I deploy today and Bob or Sue notices next week that the data isn’t correct, that’s a failure. I don’t know I’d count downtime from today until next week, but from when Bob/Sue files a ticket, the clock starts on calculating the MTTR (mean time to recovery). I don’t often see database deployments failing from the “will it compile on the production server” standpoint. Most code gets tested on at least one other system, and with any sort of process, we catch those simple errors. More often than not, we find performance slowdowns or misunderstood requirements/specifications. In those cases, some of you might consider this a failure and some may not. I suppose it depends on whether these issues get triaged as important enough to fix. While I might have a wide definition of deployment failures for most coding problems, I don’t for a performance slowdown. Far too few people really pay attention to code performance and are happy to let bad code live in their production systems for years. Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…
Many of us are faced with choices and decisions constantly in our jobs. How do we approach a problem? What should we do as a team to get the work done? How do we code or manage or test or do something else with a database? Maybe more importantly, how long do we spend deciding? I have seen teams spend way too long (in my opinion) debating options and examining possibilities. I’ve seen them take days or weeks arguing and considering edge cases and move slowly. It seems there is no shortage of reasons why something isn’t done. It can drive me a little crazy. I was listening to a podcast recently and heard about this technique, which I love. Get a whiteboard that everyone can see (physical or virtual). One person is designated to write down all the discussion items about the issue. Each person can make an argument for or against an idea for the solution, and nobody can stop that argument from being added. However, nobody can remove anybody else’s argument, and nobody can repeat an argument that is on the board. This can shorten discussions because people can’t repeat things. I’ve seen far too many debates (arguments) continue in a circle because people keep repeating things or circling back. When no one has anything new, we just take a vote and move on. I am a big fan of getting things done. Even if we don’t have the best, or optimum, or more efficient solution, we need to get moving. Perfect is the enemy of good enough, and far too often, I find technical people chasing perfection, or near perfection, at the expense of moving forward. Timebox decisions and get moving. It’s how you accomplish more, and it’s what your employer wants. Steve Jones Listen to the podcast at Libsyn, Spotify , or iTunes . Note, podcasts are only available for a limited time online.…
Welcome to Player FM!
Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.