So if we had just started deploying them AFAP, we would have been doing very well. And we would have made the progress in crafting them 50 years ago, and not just in recent 10 years. And probably no one would blame China, because they were 50 years behind us that time, instead of 5 years ahead.
Yeah, but my money is not immoral either!!! It simply sits in the bank!! Lazy! Lazy as hell! Or is under my pillow! Or even under the bed! Actually it often tries to hide from me!
And the worst thing is: when I try to be nice to my money, and take it with me into the pub... you won't guess it!! Suddenly its gone!!!
In the US, solar cannot be base load. Wind cannot be base load. Base load is a line on a graph, not a property of a power plant. Oh you mean those power plants that produce the cheapest kind of energy and run 24/7/365 above 90% ??? That are cheap power plants, that is all. You can replace them by anything that produces the power you need in the graph above. No one ever defined base load as "24/7/365 above 90%"... well, american wikipedia authors did a few years ago, but it should be long fixed.
GDPs are not comparable. Wait a moment, I call the Chinese president and tell him to change all prices by a factor of ten -> suddenly he has a 10x GDP... that was simple.
Germany talks big about their CO2 reduction plans but it's easy to see that their CO2 reductions in recent years have been minimal to nothing. In electricity? wrong In other CO2 sources? COLD WINTERS!!!
that's why the cost of electricity in Denmark and Germany is so high - they are building redundant power systems No, that is not the reason why cost for power is high. The reason are: - taxes - guaranteed feed in tariffs for renewables
hey are building redundant power systems, one renewable one "dirty", That is complete nonsense. The dirty ones we already have, that is a no brainer...
Many reasons: a) the coal plant was actually planned 20 years ago, started construction 15 years ago and got finally finished 2 or 5 years ago. b) the plants belong to different companies, one company replaces one of their plants in a scenario like described in a) c) Off-Shore wind farms are relatively recent, on shore is considered extremely inferior d) on shore needs space... at least "available space" to go there and put up a windmill e) same for solar, believe it or not, most of Germanies solar power is roof top solar (PV) on small houses, owned by the home owner, that was obviously pushed by government programs, other solar projects make not much sense (I mean thermal, except small local for hot water, but not for electricity) because of snow in winter (but that time might be over for good) There are surely more reasons.
Grid problems you only get when you produce around or more than base load from fluctuating sources. Because when demand is at base load level and you have a wind power spike you need to get rid of the power. But that is manageable, just tilt the rotors, or put some wind mills off grid.
As they get richer, they buy more AC !! 1) not necessarily 2) there are efficient ACs and inefficient ones...
Even in countries like Thailand you can build houses that don't need AC. Basically every house older than 70 - 100 years is build that way. Of course, that means "rural" style... forget the big cities:D
Or do you really think that all the countries that aren't already as developed as you, shouldn't be allowed to develop? That is exactly what many americans think. And on top of that they think if they reduce their CO2 footprint, they drop to the level of those countries (not realizing that most "developing countries" are on a far higher level than the average US citizen or city or area... despite being yearly hit by a tropical storm)
Australia is ripe for solar -- lots of empty land area with strong sunlight. They actually have interesting solar research projects.
Towers surrounded by a kind of greenhouse, creating an upwind in the tower. They put water basins below the ground of the "greenhouse" and on top of that black stones/rocks. That stores enough heat to run over night, and even a few days under cloud cover.
But I've said in other comments, not everything can be broken down into units where you can show that it works without causing additional effort. You seem to mix up tasks with subtasks. If you break something down into subtasks, then you don't demo the subtasks, but the finally finished task, that should be a no brainer. Even if the original task then needs 3 sprints.
Initial planning is best done before the sprints start. Except you want to explore possible architectures and/or solutions. I mean: you should somehow already have an idea about the scope of the project, reasonable timeframes, how many people do you have... do you definitely need to make a new team, hire more people etc.
You basically need to be at a point where some one decides: yes it is worth, to pursuit it further. At that point you should have a rough back log. However there is nothing wrong with a "planning sprint"... if you somehow can quantify what the result of the sprint will be.
That is why every software I was involved, where I had something to say, has a Currency type, and a type for everything else, like Energy and Power, or Length.
It's quite easy to state the rules, but implementing them in a usable way appears impossible. In C++ it is relatively easy. I guess in Scala, as well.
The problem comes when you want to cover everything, or most of everything.
You have "Dimensions" like "Length", "Energy", "Power", "Speed", "Time", then you have "Systems" like, "Imperial" and "Metric" then you have "Units" like "m" and "foot" or "light second" or "plank length" and then finally you have the "Representation" as in int, float, double or BigDecimal or even String.
Complicated it gets, if you have different "Interpretations" of a Dimension, e.g. "Length" can be length, width and even height. And then height X * width Y would give you an "Area" which e.g. can be passed to an algorithm calculating or dealing with wind resistance/air drag, while an "Area" made from length and width would give you a surface which is probably meaningless for air drag, but can be used to calculate e.g. expected rain gathered over a year.
Time gets nasty anyway, already distinction between a point in time or a duration is difficult, as we use the same units... hence you need own Dimensions for that (I mean, duration and time as a point in time).
If there's a date that a feature/product is expected by, that you/your team are judged by finishing by a certain date, its a deadline. Yes. And such a deadline is usually never met/reached. That is why you switch to agile, and accept that it takes the time it takes instead of failing a deadline and start complaining.
Because I don't search for stuff like this, why don't you search yourself? I don't know how to find a graph for this "I see you still avoid quoting CO2/MWH" and I really have more important things to do than googling several hours for stuff I'm not interested in.
Wind and solar started to be added in significant numbers around 1985... no idea where you have 2008 from. What has 2008 to do with that? The EEG first came into force on 1 April 2000 and has been modified several times since. https://en.wikipedia.org/wiki/...
Before that we had laws specific to solar and wind for subsidizing... the first wind farm at my place was build 1986. And it was not the first in Germany.
Extreme Programming e.g. has the mantra "Refactor Mercyless", no idea how you can accumulate technical debt in an agile project and not do everything to avoid it.
The appearance of "slowness" is completely irrelevant. If you drive with the car a long route, there will be fast parts and slow parts. That is in software development the exact same thing, regardless of process.
I mean, maybe you enjoy working on shoddy software that doesn't actually meet the goals of the customer, just the specs, but I find it sad. Most of my software were I was involved was delivered without any bug in production. The last 15 years nearly all projects were agile projects. The only bugs in production are those that were introduced before me and could not be fixed during my time in the project. That new bugs escaped QA was and is extremely rare.
If you accept that you accumulate technical debt, and have bugs and lose track what is done and what not, or if the architecture is sound or not: then you are not doing agile software development but bullshit development Fix it. And don't complain about "agile" if you simply are not agile and can not address your problems. The stuff you quarrel about is your teams problem. Or the problem of your organization, or both!!
Depends on what you want to teach. I agree that Java is a bad teaching language, but because of its verbosity (every attribute needs 'private' and every method 'public' - that should be the default!), not because of other things. In CS you usually want to abstract away stuff like memory management. I actually don't know anyone who learned C++ in the university out of a requirement. My university evolved from Pascal to Java (in CS). Only special projects used C or if the students wanted, C++. Basically everyone I know who does/did C++ is self taught.
It was easy to start with C for imperative programming, then easy to move on to C++ for object orientation. That is actually for many people not easy. It is much simpler to start with objects/classes right away.
Slashdot Mirror
So if we had just started deploying them AFAP, we would have been doing very well.
And we would have made the progress in crafting them 50 years ago, and not just in recent 10 years. And probably no one would blame China, because they were 50 years behind us that time, instead of 5 years ahead.
Greenpeace always said: go for wind and solar and biomass.
And actually, we all know: nuclear is bad. So what is your point?
Oh, you got not evacuated from Chernobyl or Fukushima? Wow, what a relieve for you ...
Yeah, but my money is not immoral either!!!
It simply sits in the bank!! Lazy! Lazy as hell!
Or is under my pillow!
Or even under the bed!
Actually it often tries to hide from me!
And the worst thing is: when I try to be nice to my money, and take it with me into the pub ... you won't guess it!! Suddenly its gone!!!
Rofl ...
The short sighted idiots again ...
If you plan a nuke now, when will it be finished?
If you plan 1000 nukes now, where will the fuel come from?
If you have to supply 1000 nukes with fuel, how do you transport it?
What has that to do with "lefties"?
Someone does not agree with you on a topic, so he is a lefty?
If someone says "EU level" he obviously means average EU versus average american.
Or do you want me to single out a very bad US example state?
In the US, solar cannot be base load. Wind cannot be base load. ... well, american wikipedia authors did a few years ago, but it should be long fixed.
Base load is a line on a graph, not a property of a power plant.
Oh you mean those power plants that produce the cheapest kind of energy and run 24/7/365 above 90% ??? That are cheap power plants, that is all. You can replace them by anything that produces the power you need in the graph above. No one ever defined base load as "24/7/365 above 90%"
I'm pretty sure, you already have enough power to cover your "base load".
Base load is a line on a graph, not a property of a power plant.
Depends on which metric you use :D
GDPs are not comparable. Wait a moment, I call the Chinese president and tell him to change all prices by a factor of ten -> suddenly he has a 10x GDP ... that was simple.
Because they have nukes and carriers and Trump ...
Germany talks big about their CO2 reduction plans but it's easy to see that their CO2 reductions in recent years have been minimal to nothing.
In electricity? wrong
In other CO2 sources? COLD WINTERS!!!
Get a damn clue.
that's why the cost of electricity in Denmark and Germany is so high - they are building redundant power systems
No, that is not the reason why cost for power is high.
The reason are:
- taxes
- guaranteed feed in tariffs for renewables
hey are building redundant power systems, one renewable one "dirty", ...
That is complete nonsense.
The dirty ones we already have, that is a no brainer
Many reasons: ... at least "available space" to go there and put up a windmill
a) the coal plant was actually planned 20 years ago, started construction 15 years ago and got finally finished 2 or 5 years ago.
b) the plants belong to different companies, one company replaces one of their plants in a scenario like described in a)
c) Off-Shore wind farms are relatively recent, on shore is considered extremely inferior
d) on shore needs space
e) same for solar, believe it or not, most of Germanies solar power is roof top solar (PV) on small houses, owned by the home owner, that was obviously pushed by government programs, other solar projects make not much sense (I mean thermal, except small local for hot water, but not for electricity) because of snow in winter (but that time might be over for good)
There are surely more reasons.
Grid problems you only get when you produce around or more than base load from fluctuating sources. Because when demand is at base load level and you have a wind power spike you need to get rid of the power. But that is manageable, just tilt the rotors, or put some wind mills off grid.
As they get richer, they buy more AC !! ...
1) not necessarily
2) there are efficient ACs and inefficient ones
Even in countries like Thailand you can build houses that don't need AC. Basically every house older than 70 - 100 years is build that way. Of course, that means "rural" style ... forget the big cities :D
Or do you really think that all the countries that aren't already as developed as you, shouldn't be allowed to develop? ... despite being yearly hit by a tropical storm)
That is exactly what many americans think.
And on top of that they think if they reduce their CO2 footprint, they drop to the level of those countries (not realizing that most "developing countries" are on a far higher level than the average US citizen or city or area
Australia is ripe for solar -- lots of empty land area with strong sunlight.
They actually have interesting solar research projects.
Towers surrounded by a kind of greenhouse, creating an upwind in the tower. They put water basins below the ground of the "greenhouse" and on top of that black stones/rocks. That stores enough heat to run over night, and even a few days under cloud cover.
There is a kind of prototype in Spain: https://en.wikipedia.org/wiki/...
But I've said in other comments, not everything can be broken down into units where you can show that it works without causing additional effort.
You seem to mix up tasks with subtasks.
If you break something down into subtasks, then you don't demo the subtasks, but the finally finished task, that should be a no brainer. Even if the original task then needs 3 sprints.
Initial planning is best done before the sprints start. Except you want to explore possible architectures and/or solutions. I mean: you should somehow already have an idea about the scope of the project, reasonable timeframes, how many people do you have ... do you definitely need to make a new team, hire more people etc.
You basically need to be at a point where some one decides: yes it is worth, to pursuit it further. At that point you should have a rough back log. However there is nothing wrong with a "planning sprint" ... if you somehow can quantify what the result of the sprint will be.
That is why every software I was involved, where I had something to say, has a Currency type, and a type for everything else, like Energy and Power, or Length.
It's quite easy to state the rules, but implementing them in a usable way appears impossible.
In C++ it is relatively easy. I guess in Scala, as well.
The problem comes when you want to cover everything, or most of everything.
You have "Dimensions" like "Length", "Energy", "Power", "Speed", "Time", then
you have "Systems" like, "Imperial" and "Metric" then
you have "Units" like "m" and "foot" or "light second" or "plank length" and then finally
you have the "Representation" as in int, float, double or BigDecimal or even String.
Complicated it gets, if you have different "Interpretations" of a Dimension, e.g. "Length" can be length, width and even height. And then height X * width Y would give you an "Area" which e.g. can be passed to an algorithm calculating or dealing with wind resistance/air drag, while an "Area" made from length and width would give you a surface which is probably meaningless for air drag, but can be used to calculate e.g. expected rain gathered over a year.
Time gets nasty anyway, already distinction between a point in time or a duration is difficult, as we use the same units ... hence you need own Dimensions for that (I mean, duration and time as a point in time).
If there's a date that a feature/product is expected by, that you/your team are judged by finishing by a certain date, its a deadline.
Yes. And such a deadline is usually never met/reached. That is why you switch to agile, and accept that it takes the time it takes instead of failing a deadline and start complaining.
Why should I not commit buggy code?
It is on my private branch ... it gets merged/pulled into the trunk or sprint branch when everything is fixed.
--trunk--............---------M
\---sprint branch-------------------/
\---- my feature branch---/
Then you are definitely doing it wrong. But in current times it should be easy to find a better job :D
Because I don't search for stuff like this, why don't you search yourself? I don't know how to find a graph for this "I see you still avoid quoting CO2/MWH" and I really have more important things to do than googling several hours for stuff I'm not interested in.
Wind and solar started to be added in significant numbers around 1985 ... no idea where you have 2008 from. What has 2008 to do with that? The EEG first came into force on 1 April 2000 and has been modified several times since. https://en.wikipedia.org/wiki/...
Before that we had laws specific to solar and wind for subsidizing ... the first wind farm at my place was build 1986. And it was not the first in Germany.
Well,
then you simply are doing wrong.
Extreme Programming e.g. has the mantra "Refactor Mercyless", no idea how you can accumulate technical debt in an agile project and not do everything to avoid it.
The appearance of "slowness" is completely irrelevant. If you drive with the car a long route, there will be fast parts and slow parts. That is in software development the exact same thing, regardless of process.
I mean, maybe you enjoy working on shoddy software that doesn't actually meet the goals of the customer, just the specs, but I find it sad.
Most of my software were I was involved was delivered without any bug in production. The last 15 years nearly all projects were agile projects. The only bugs in production are those that were introduced before me and could not be fixed during my time in the project. That new bugs escaped QA was and is extremely rare.
If you accept that you accumulate technical debt, and have bugs and lose track what is done and what not, or if the architecture is sound or not: then you are not doing agile software development but bullshit development Fix it. And don't complain about "agile" if you simply are not agile and can not address your problems. The stuff you quarrel about is your teams problem. Or the problem of your organization, or both!!
Depends on what you want to teach. I agree that Java is a bad teaching language, but because of its verbosity (every attribute needs 'private' and every method 'public' - that should be the default!), not because of other things.
In CS you usually want to abstract away stuff like memory management. I actually don't know anyone who learned C++ in the university out of a requirement.
My university evolved from Pascal to Java (in CS). Only special projects used C or if the students wanted, C++.
Basically everyone I know who does/did C++ is self taught.
It was easy to start with C for imperative programming, then easy to move on to C++ for object orientation.
That is actually for many people not easy. It is much simpler to start with objects/classes right away.
The original sprint length in both Scrum and XP was 6 weeks or 12 weeks. Depending on maturity of the team. The less mature, the longer the sprint.
No one in his sane mind will recommend a 3 or even 2 weeks sprint to a team that has not managed to deliver predictable sprint results.