Being a high ranking general must be difficult. One problem you may run into is that you must choose your words very carefully. Otherwise the following might happen…
General: Hands assistant cold food that needs to be reheated. “Nuke this for me.” Assistant: “What yield of atomic bomb should I use, sir?” General: “What are you talking about?” Assistant: “You asked me to nuke this. I need to know what yield of atomic bomb to use.” General: “You asshole. Nuke is slang for microwave. I want you to heat that up in the microwave for me.” Assistant: “Sorry sir. What settings should I use?” General: “Microwave it on high for 1 minute.” Soldier: Very well sir!
Being a high ranking general must be difficult. One problem you may run into is that you must choose your words very carefully. Otherwise the following might happen…
General: “Nuke it from orbit. It’s the only way to be sure”. Stops paying attention and as a result does not hear the soldier reply. Soldier: “Very well sir!”
…
Some time goes by. There is an atomic bomb detonation at the target that was being discussed earlier.
…
General, shouting at Soldier: “You asshole. It was just a famous quote from a famous movie. It was not an order.”
…
Hopefully there are many safeguards in place to keep this from happening in all militaries that actually have access to atomic bombs. If not, may god have mercy on us all.
You can attempt to idiot proof something by guarding against mistakes typically made by the idiots of today.
You can attempt to future proof something by guarding against foreseeable mistakes that might be made by reasonable people at some point in the future.
However, you cannot future idiot proof anything. Idiots keep getting more idiotic. There is no way to predict what mistakes the idiots of tomorrow might make.
I curse you. I cast upon you the greatest curse I have the power to cast.
May you live a long and pointless life. And many years from now when you are laying on your death bed, may you find yourself alone instead of being surrounded by friends, family, and loved ones because you have driven them all away through your evil, hateful acts. And may you, on the day you die, finally realize and accept just how evil you are. And may your last thought in this life be as follows. “What awaits me? Will it be a reward? Will it be rest, peace, and forgiveness? Or will it be a well deserved punishment?”
If you create a new programming language that is meant to be a successor of an existing programming language, do not break every single rule of the original language.
In C, C++, C#, and many simular languages data types are on the left and variable names are on the right. Anyone who has any experience in these programming languages expects any programming language that claims to be a successor to follow this most basic of syntax rules. This rule is such a basic rule of the language you should not even consider breaking it for a so called successor language.
The Carbon Programming Language breaks that rule.
Maybe people who have not ever used C and C++ will be willing to learn the Carbon Programming Language, but people with 20+ years of experience will hesitate because the code is too different.
This should be obvious.
Putting the variable name on the left and the data type on the right may make parsing easier, but millions of people who have experience in C or C++ or C# expect the data type to be on the left. Google, by going against these expectations is greatly limiting the adoption of the Carbon Programming Language.
Why does Visual Studio always do the wrong thing when creating a new solution or project file in an existing directory.
Consider the following scenario.
There is source code but no project file in the directory c:\Path\To\ProjectName.
You create a new project file named ProjectName in the directory c:\Path\To\ProjectName. You expect the project file to be directory c:\Path\To\ProjectName\ProjectName.vcxproj because that makes sense.
Note that ProjectName is already repeated twice in that path.
What Visual Studio actually does is create a directory named ProjectName in the directory c:\Path\To\ProjectName and then places the file ProjectName.vcxproj in that directory so that the full path to the project file becomes c:\Path\To\ProjectName\ProjectName\ProjectName.vcxproj.
Now you have a path where ProjectName is repeated three times.
Every time this happens I have close the solution file, to go to the directory in Windows Explorer, move the project file up a level, delete the extra ProjectName directory, manually edit the solution file in a text editor, then reopen the solution file in Visual Studio. Please, just put the project file in the specified directory.
Please. I am begging you. If you release NuGet packages sign both the Debug and the Release DLLs. Do not just sign the Release DLLs.
I wasted four hours today debugging the following exception: “FileLoadException: A strongly-named assembly is required. (0x80131044)”.
I was debugging the debug build of an application that uses the Titanium.Web.Proxy version 3.1.1397, obtained using NuGet. The Titanium.Web.Proxy uses BouncyCastle.NetCore version 1.8.10.
I have a python script that copies the build output from the output directory to the appropriate location on my test PC where I have the product I am working on installed. This python script replaces the files already present in the application installation directory with the files produced by building the product on my development PC.
The build process, which uses MSBuild, copies the DLLs for BouncyCastle.NetCore and Titanium.Web.Proxy to the output directory. This is useful for release builds because the installer project pulls all DLL and EXE files from the build output directory. My python script previously copied the BouncyCastle.NetCore and Titanium.Web.Proxy files to my test PC in addition to all the DLL and EXE files for the application.
The problem is that the Debug DLLs for BouncyCastle.NetCore and Titanium.Web.Proxy are not signed. When a .NET assembly depends on another assembly and the dependent assembly is not signed .NET will throw a “FileLoadException: A strongly-named assembly is required. (0x80131044)” exception when the first assembly attempts to load the dependent assembly.
It took me four hours to find out why this exception was occurring.
Please, if you are writing an article like Git Fixes: The Current Branch Has No Upstream Branch in which you attempt to explain how to solve the “fatal: The current branch has no upstream branch” error, do not use the wrong branch name in your sample commands.
For example, do not claim that the problem can be solved with the following command.
git push -u origin master
This error cannot in any way be solved by the above command. Why? Because as you correctly point out in the beginning of your article, the reader is not working in the master branch. The only reason the reader saw the error in the first place and did a Google search to find your article is they created a local branch that is most definitely not named master and an error occurred when they attempted to push the changes. The above command is only valid if they are working in the master branch.
The moment the reader sees master in the above command when they know for a fact that it is not correct the begin to question you credibility.
You started off so well in the third paragraph when you included the following.
git push --set-upstream origin <branchname>
In the above example <branchname> makes it clear that the reader is supposed to insert the name of their own branch in that location in the command.
You started off so well. But then you messed up by putting master where you should have put <branchname> throughout the rest of the article. The moment a reader sees master where they know for a fact that it does not belong, your poor reader may go to another less detailed source rather than figure out what you meant to say. I had to read ten other less well written articles before I figured out what you meant to say.
Reading your article could have been a pleasurable experience causing me to be thankful that the solution was so easily found and implemented. Instead it became an hour long headache.
Computer manufacturers and computer accessory manufacturers really need to use consistent terminology. Their failure to do so makes things unnecessarily difficult.
I am considering buying a computer from Dell since one of my main computers does not support Windows 11. According to Dell the computer has the following display ports: 1x HDMI 2.0b, 1x DisplayPort 1.4, 1x Dual Link DVI.
The problem is that I need to be able to use this computer with an existing KVM that uses VGA. Therefore I will need to use adapters. The question is what adapters do I need.
Computer accessory manufacturers do not use the Dual Link DVI terminology at all. They use DVI-D and DVI-I. In order to determine what adapter to get I had to go to the Different types of monitor ports page and compare the pictures on Dell.com with the pictures on the Different types of monitor ports page to determine that Dual Link DVI is apparently the same as DVI-D. Therefore the Active DVI-D to VGA Adapter should allow me to connect a VGA monitor cable to the Dual Link DVI port.
Computer accessory manufactures do use the term HDMI. The problem is that not one of the search results for HDMI 2.0b to VGA adapter say anything about the HDMI version. They are HDMI to VGA adapters. No version number information is provided at all. I have to hope that the Gold-Plated HDMI to VGA Adapter will do the job.
Thanks to the use of inconsistent terminology buying this computer has been an arduous and very unpleasant experience.
This blog post is for any software engineers who are involved in programming or designing a user interface.
If someone performs a user interface action that should result in an instantaneous and clearly visible response they will only wait patiently for that response for a brief period of time.
If after a five second delay they do not see the expected clearly visible response they will perform the user interface action again, perhaps multiple times if the delay continues for another five seconds or so.
If for some reason there is a delay that prevents the expected instantaneous and clearly visible response, please, for the love of whatever deity or great power you follow, DO NOT PERFORM THE RESPONSE MULTIPLE TIMES.
The multiple user interface actions were not in any way a request to perform the response multiple times. They were multiple increasingly desperate attempts to get the response a single time.
For example, if the user is pressing enter on a desktop icon that starts a program that displays a message box before the main function is even called, they will press enter on the desktop icon multiple times if for some reason it takes between five and sixty seconds to start the application when it normally starts in far less than a second.
Trust me. The user has already started screaming at you by the time they have to hit enter on the desktop icon a third time because the message box still has not been displayed in response to the request to start the application that was made fifteen seconds earlier.
If you then start that application one time for each time they pressed the enter key on the desktop icon when your badly broken operating system finally realizes the user is desperately trying to start it the poor user might end up having a stroke because of the rage they are now experiencing!
Another example is opening a menu such as the start menu or an application menu. Normally this is a very quick operation that takes less than a second. So if five seconds after they pressed the key to open the menu the user does not see the menu, they will press the key to open it again. On the rare occasions when something delays the opening of the menu they may have pressed the open menu key four or five times before it is opened.
That does not mean they want the menu to be opened, then closed, then opened, then closed…
The multiple presses of the key to open the menu were multiple increasingly desperate attempts to open the menu once. By the second attempt the poor user is screaming at you. If you do the open menu, close menu, open menu, close menu, … foolishness it is very likely that the poor user might end up have a stroke because of the rage they are now experiencing!
These are problems I experience very often with Microsoft Windows. To be fair I have seen it with Linux and Mac OSX as well, but no where near as often as I see in in Windows.
Fuck you very much Microsoft for the wonderful user experience of Windows and every single Microsoft product I have every used!If I believed in hell I would wish for everyone responsible for these wonderful user experiences to suffer eternal torment in the hottest and most fiery section of hell!
Thank you for listening to me vent. I feel much better now.
Here is a song that expresses my heartfelt feelings towards Microsoft. Enjoy.
YekNeb 