Deadlock, Integration, Stock, Configuration

• Enjoyed updating data which is locked by select statement. I thought it would be trivial, and it probably is. But now something is causing permanent deadlock, which isn't resolved by deadlock detection interestingly. Something I didn't expect is happening. Yup, my feeling was similar to other users on forums. With every other database I can do it. No problems. And finally, after rereading all code, I found out that I were actually using two separate connections to the same database. The first connection issued the select and locked the records correctly and then the same thread and process, tried to update the data using alternate connection and the locks naturally prevented it. Duh! Issue solved, daily programming fun. Obvious fail is obvious, when you just know what's causing it. This rarely happens when writing new code, but when trying to change old code in hurry, these are just kind of issues you'll hang up with.
• Did I say system integration is a quick tasks? Well sometimes. But now here's one project going where integration work has been done for one year, and it's not done yet. Usually biggest issue is that the customer doesn't know what they want, and then starting changing it over and over again. Some parts of this project have been now completely rewritten around five times, without being in production even once. So, what's the point of writing "top quality code" if it never gets even used before getting scrapped?
• Lot's of stock keeping process discussion and payment, loyalty, bonus and benefit integration discussion. That's kind of funny in a sense, it's all quite simple and there are best practices which to follow. In some cases, it's interesting to see, how wheel is being reinvented. And even basic processes are discussed over and over again. Even if it's very clear that at least in technical sense there's very little that can be done about it and it's totally obvious and can be implemented as needed to full-fill the specific requirements. Once again, the problem unfortunately often is, that customer doesn't need what they need nor understands what the limitations are if specific process model is chosen. Larger the works groups and organizations, the funnier the process is. Even if it's technically something that could be specified very easily. Like thing A has to happen before B. Unfortunately at time,s there are even technical flaws in the process and then there's the worst part. People, those are very unreliable and aren't following agreed protocols. So, even if everything is "perfect" humans still manage to mess it up. Extremely simple example is that thing A can be only sold, if there's stock availability (not reserved) for it. And similar things like if you're eligible for specific benefit / discount, freebie or whatever. If you draw process chart about it, it's easy to identify the requirements. Yet in reality people manage to mess it up completely. As well as the exception handling, what happens in specific situations. This is also a case where state machine like thinking helps.
• Encountered ConfigParser BasicInterpolation issue with % sign. I didn't even remember it, even if I've read the configparser documentation several times. This is good example of modern computing platforms and issues, where versatility is actually the problem. Very simple things like %password% get broken, because the field is being processed by way too advanced processor. Similar hidden features are behind just oh so many security issues. It's very handy if you can do extremely powerful tricks, like run code from variable or execute custom code from any string or something similar. But it can also seriously undermine security, especially if most of users don't even know that this kind of feature exists and assume it being safe. - Did I say something new? No, just all the old patterns repeating itself. Fixes using %% syntax or interpolation=None or using RawConfigParser.
• WebDAV - Refreshed my memory about it, and requirements for configuring IIS to allow WebDAV file access.

2019-07-21