By default, print() statements are not output to the console when you run a pytest. To see output (e.g. for debugging a test), run your tests with the -s option.
From here.
Website down for 24 hours: SSL certificate update failed – checking the contents of your certificate bundle
My SSL certificate for this site was about to expire this week, so I paid for an update for another year and then proceeded to upload my new certificate bundle to my server. Having been through this process a few times, I have a couple of posts describing the steps for configuring nginx with SSL certs here:
… and how to create a certificate bundle here:
I normally concatenate the root, intermediate and my site certificate manually before uploading using the steps in the post above. This time though I noticed the updated certifcate had a bundle download, so I downloaded this and uploaded straight to my site and then restarted…
Unfortunately, since I run nginx in a Docker container, on restarting the container it failed and then went into a restart loop. While constantly failing and restarting like this, it’s not possible (that I know of) to ‘docker exec -it bash’ into the container since it hasn’t completely started. In hindsight maybe ‘docker log’ would have told be what I needed to know, but I wanted to look at the /var/log/nginx/error.log inside the container to see what the issue was. I found a neat trick to do this which I’ll cover in another post.
In the meantime, I found the error in the nginx error.log was this:
2024/06/12 16:31:02 [emerg] 56#56: SSL_CTX_use_PrivateKey_file("/etc/nginx/ssl-certs/my-site.key") failed (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
This seemed odd since I generated my CSR for the new certificate on the server and had the key for the request and new certificate. This post for this error luckily had suggestions to look at the contents of the bundle, using:
openssl x509 -noout -text -in yourcert.cert
And exactly as one of the answers suggested, the ‘Subject:’ field in the certificate was not for my domain, it was for the CA instead. The bundle that I downloaded after purchasing my new certificate contained the CA and the Intermediate certs but not the cert for my domain… I should have followed my own instructions for combining all three and including my own site certificate.
I created my new bundle by hand, uploaded to my server and now everything is back to normal with the new SSL certificate.
In hindsight I should have tested my updates on my test server before upload direct to my live server, but since moving house recently I no longer have the HP rackserver I had before, on which I used to run a test server that mirrored the config of my live site. Lesson learned, I need to set up a new test server…
Generating code is easy; Understanding customer requirements is hard. (Or, why AI generated code is still decades away)
There’s been a lot of attention on GitHub’s CoPilot in recent months, it generates code for you based on the context of your other surrounding code in your editor, filling in the blanks with what their trained Machine Learning model ‘thinks’ you are attempting to code.
While impressive, it’s questionable from a legal perspective whether you can or should build a system for your company or a client based on code generated from other code shared by other developers and companies online who are unaware that their assets would be used by someone else in the future in the generation of new code derived from theirs. Generated code from a model that is trained on code written by other developers that have no contractural relationship with your company or client has legal consequences and questions that I don’t think at this point have been properly addressed by our industry, such as:
- who owns the generated code?
- who is responsible for the generated code when it fails?
- who is responsible for fixing bugs in the generated code? (the obvious answer is you and your company if you decide to use that generated code, but what if those bugs cause losses to your business as a consequence (from outages, or other functional issues), or worse, loss of lives (a risk of any safety critical code)
There’s currently ongoing legal action against Microsoft, claiming that Microsoft used developer’s code in their GitHub projects without permissions.
Writing code is not the hard part
AI code generation does not address any of the most significant problems in software development. Code Generation helps to write lines of code, but the act of typing lines of code at your keyboard is not where the majority of time and effort is spent in the overall process of building a software product or system. Generating code via any approach, whether using models (e.g. UML Class diagrams) or using AI Machine Learning trained models, is solving the smallest and probably simplest part of the software development process. Overall there is far more time and effort spent before developers start to actually write any lines of code, by the time you start writing code you’ve already reached the easy part, the majority of the hard work has been done. Areas that are considerably harder and/or where more time and effort is spent include:
- understanding the customer’s problem (understanding the requirements)
- designing an effective solution to solve the customer’s problem, given a number of constraints (e.g. time, budget and quality)
- finding acceptable compromises between competing priorities and needs between different areas of the business
What’s Next?
It can’t be denied that any tool that reduces time and effort to produce appropriate and effective solutions is still worthwhile, and there’s obviously improvements that we’ll see in the coming years with the current AI Models and their ability to help with code generation.
Whether the technology will continue to improve to the point where it can be fed a collection of vague requirements and generate a working system is still yet to be seen.
Microsoft open sources GW BASIC, originally launched in 1983
Microsoft has open source’d GW BASIC, originally released in 1983. You can browse the source here on GitHub, but the article looking back at what was also going in in tech in 1983 is also a fascinating look back in history.