There’s your Christmas present.
There’s your Christmas present.
24lb turkey, started it at 10:30 last night, looking golden delicious this morning!
Because of the performance issues with starting up a Docker for Windows container, I decided to uninstall it and go back to the Docker Toolbox and try out .NET Core 2.0. I’m much more pleased with the experience — Docker is definitely a lot more usable with a Linux OS! Furthermore, it turns out Hyper-V totally Elephant’ed my video drivers (there’s a lot of posts on the web about that), so NetFlix and “streaming” became a contradiction in terms.
Disabled Hyper-V (a much less painful process than enabling it) and uninstalled Docker. Yet, WTF, there is still 20GB of docker crap left in the ProgramData folder.
And it can’t be deleted — the typical “Administrator access is required” but my user account is an administrator BS in Windows. Find a post on the Docker forum that basically says “yeah, deleting ProgramData\Docker is really hard, we could do a better job of it, you should use docker rmi before uninstalling Docker.” Or something like that. Great, if there’s a command I can run manually, why can’t the uninstaller run it?
So more Googling, trying to take ownership of the file (fail) and I find this post that basically says:
What do you know, that worked. I’ve now reclaimed the 20GB that Docker for Windows failed to install.
Unfortunately, uninstalling Docker for Windows had a few pain points as well. In my not-so-humble opinion, Microsoft has a ways to go for Docker for Windows to be a viable container development option.
Thank you, Arnold, for this concise and direct message.
This was a fun article to write (here on Code Project). The neat thing about the solver (besides the interactive UI) is that I demonstrate three techniques for solving the puzzle:
From Code Project:
If it walks like a duck, and quacks like a duck, it’s probably gonna throw exceptions at runtime. – Mladen Janković
Granted, I borrowed that image from here, where the author views people like me as “unhappy dogmatists who can’t bring themselves to leave the kiddie pool of strong typing.” Yes, I am rather dogmatic about strong typing! But to the point…
David R. Maclver wrote an interesting post “Static typing will not save us from broken software.”
davidMacIver = HesGotSomeGoodPoints() davidMacIver = ButHesAlsoWrong()
Make it more expensive to write broken software – write in a non-static typed language
Make it cheaper to write correct software – write in a static typed language
But because these bugs [those that happen in production] are relatively minor
due to ground-based computer software which produced output in non-SI units of pound-seconds (lbf s) instead of the SI units of newton-seconds (N s) specified in the contract between NASA and Lockheed.
would not have cost the taxpayers $327.6 million
Dealing with type errors in a non-static language is not cheaper. I spend time writing unit tests and verifying the runtime by hand to ensure type correctness that I do NOT spend with static typed languages. Running an app only to discover I’m using a duck-typed variable before I’ve assigned something to it is a time waster. The benefits of static typing far outweigh the benefits of non-static typed languages, and I’m sorry David, that’s not opinion, but measurable fact.
Can duck-typed languages save time? Sure! I can replace a class instance that interfaces with hardware with a class instance that mocks the hardware as simply as the code above. I can add fields to a class outside of the class simply by making an assignment.
All of which are cheats and laziness, break the “code as documentation” fallback, and make duck-typed code more error prone and difficult to maintain.
Most existing static type systems also come with a build time cost that makes testing in general more expensive.
And the unit tests that duck-typed languages require often (in my experience with a small Ruby on Rails web app) take longer to run than compiling much more complex web sites.