968 karma · joined August 10, 2017
And that's what makes it a nightmare for the rest of us.
“Gotta hurry past this café so the music won’t get my video copyright striked, lol!”
I worked for a major Danish power company for 2.5 years, but I mostly did mathematical modelling and implementation of the production planning system.
They are insulated like a thermos (but more efficiently), and since they are really big, they have small surface area compared to their volume.
It is a VERY efficient way to store heat over shorter periods, like a week or so, and it helps making power plants more cost efficient.
The best way to make it efficient for long term storage (like seasonal storage) is to
1. Make them huge
2. Make them ball shaped
3. Put them underground
There has been talk of tryibg this out in Denmark. Almost all our powerplants (i.e. the not-really-old ones) are combined heat and power plants, and because we use district heating water to create a vacuum behind the power producing turbines turbines (instead of sea water) we go from a theoretical limit on the energy efficiency of around 60% to 98%, as we do not pump out the excess heat into the sea.
Newer combined heat and power plants have an energy efficiency of around 95% to 96%. The trade of is a slightly lower vacuum, meaning less production of power. However, we can scale up heat production to reduce costs of running power plants when energy prices are low (or even negative).
One of the things I got from this was that maybe we should do more to design structured interfaces instead of counting the number of clicks needed to transition to the page you're looking for.
Many enterprise applications (especially web based ones) are horrible to navigate, and some people spend most of their working days in them. It's terrible.
Pure validation has a lot of problems, namely that you have to validate the data on all levels for the invariants required at that level.
For me, the funny thing about this article is that I kind of had the core insight just yesterday while hacking together a cli framework, but like the author, I couldn't quite explain what I learned.
Also, it would seem that the panic response is evolved for the benefit of the flock, not the individual, as it spreads rapidly; if one person panics, more will follow suit.
fibs = 0 : scanl (+) 1 fibsThen tasks cannot move to your "Done" column unless documentation is written and passes review. If you enforce column limits documentation it will also block other tasks if not completed.
As far as I know, only homeless people don't have an adress in Denmark.
EDIT: Great, now I'm downvoted as well! Huzzah!
A year or so ago I had a semi-breakdown over the fact that all the best practices I stood by was more or less just a regurgitation of what some software "guru" had to say on the subject. I didn't know if it was true, but I damn sure believed it.
I believed so hard that my opinions and feelings was almost (if not entirely) religious in nature. Sure, I had some experiences with things that absolutely did not work, some techniques that worked under the specific circumstances I applied them in.
But in general? After 10 years of software development, I can't tell you why I solve a specific kind of coding problem the way I do. I can give you a lot of reasons, but only based on vague hand-wavey stuff such as feelings and experience.
Don't get me wrong; experience is really great. But it's not the same as truth. What works for me might not work for you, and vice versa. And what I believe works for me might in fact slow me down.
And there's no real way for me to know for sure.
Definition 1C in the link you provided lists "a means to an end" as a definition of a tool, which I explicitly mentioned code was.
So I must concur, code is a tool. But I'm adamant that it is also a liability.