Civilization VI [Steam] had the massive Fall 2017 patch released for Windows on October 19th, but sadly the patch is taking a while for Linux (and Mac).
For those hoping to dive back into Civilization VI with the refreshed game over the holiday, this is sure to be rather dissapointing news. Especially since it's quite a big patch and it means Linux gamers are currently missing out on the Khmer & Indonesia DLC pack. Here's what Aspyr Media said in their update:
UPDATE 12/20/2017
Due to extensive development and necessary code fixes, this patch has taken significantly longer than previous updates. We will not be able to release the Mac and Linux Khmer and Indonesia update until sometime after the holiday break. We apologize for any inconvenience.
I'm sure they have perfectly valid reasons, I just hope they haven't encountered a really nasty bug that takes a while to work around. Even so, it's hard not to be dissapointed since this patch is now over two months late. You can keep an eye on this page for updates.
Full details on what the patch does is available here.
Its the same as leaving variable name after everything else was changed and thus the variable name no longer correspond with its function.
Quoting: tuubiIgnoring the condescending tone of your replyI guess both our comments have that condescending tone. I apologize if that triggered something inside you, that was not my intention.
Quoting: tuubiis that supposed to be an argument against code comments?No, as I stated, there are lots of valid comments. Mostly about WHY a certain piece of code has to be there, assumptions, preconditions, external references etc.
I discourage comments about WHAT a certain code is doing, these kind of (simple or ugly) comments should be part of the code itself.
// This is needed due to this and that
var i = 0; // iterates over list Y
// Does something
[a few lines of code]
// Does something else
[a few lines of code]
// Does something different if this is given
if (this == that && that == something)
{
[a few lines of code]
}
should imho be written as
// This is needed due to this and that
var yIterator = 0;
DoSomething();
DoSomethingElse();
if (ThisIsGiven())
DoSomethingDifferent();
...
The second version is much more robust against rework and refactoring, don't you think? Note that I was taking about several years, i.e. ten, between Developer/Team A and B, where A and B have never spoken to each other. Development methods (coding styles, review procedures, team organization) were quite different ten years ago and will be again quite different ten years in the future. Code that has to to survive this time span will get messy over time due to different approaches how to solve things, especially because teams doing maintenance later are usually not the strongest ones. Having code as robust as possible, that includes removing ugly comments and replace them with method extraction and better naming, helps to stand the test of time a little bit better.
Edit: Extend sample.
Last edited by jens on 29 December 2017 at 2:26 pm UTC
Quoting: GuestThat book has the word "agile" in the full title. No way I'm going to read it. I despise that term.Yeah, shame that this term has been so heavily abused, especially by so-called scrum masters that never really understood what this is about. The original meaning/the statements from their manifesto are still very valid if one reads with care.
Quoting: GuestOh, and medical device development isn't suited to "proper" agile. It needs documentation for every minor detail and change (with good reason really).Yes, sure, should have added that there are branches that needs a different or adapted treatment. There is no "one size fits all". If someone claims so for whatever, it ain't true.
Last edited by jens on 29 December 2017 at 10:56 am UTC
Where I currently work, I even say a Nagios check that is written in perl, that then calls a bash script to set up the environment, which also calls another perl script, which then runs a bash script...
I am pretty shit at coding, but even I know that is just a jungle of wtf?
Quoting: slaapliedjeMy 'favorite' thing to see now is a mish mash of languages inserted into scripts. I am in the middle of trying to teach myself python while rewriting this python script that currently uses a perl script/library, and several bash scripts that then run fabric commands....I guess that's how the Unix-like ecosystem of "small tools that do one job well" is built. As long as the scripts are well separated and have clean interfaces, it doesn't really matter how they're scripted. But yeah, that could also be a jungle of wtf.
Where I currently work, I even say a Nagios check that is written in perl, that then calls a bash script to set up the environment, which also calls another perl script, which then runs a bash script...
I am pretty shit at coding, but even I know that is just a jungle of wtf?
Quoting: tuubiQuoting: slaapliedjeMy 'favorite' thing to see now is a mish mash of languages inserted into scripts. I am in the middle of trying to teach myself python while rewriting this python script that currently uses a perl script/library, and several bash scripts that then run fabric commands....I guess that's how the Unix-like ecosystem of "small tools that do one job well" is built. As long as the scripts are well separated and have clean interfaces, it doesn't really matter how they're scripted. But yeah, that could also be a jungle of wtf.
Where I currently work, I even say a Nagios check that is written in perl, that then calls a bash script to set up the environment, which also calls another perl script, which then runs a bash script...
I am pretty shit at coding, but even I know that is just a jungle of wtf?
Makes it really hard to troubleshoot, that is for sure.
See more from me