• 0 Posts
  • 28 Comments
Joined 3 months ago
cake
Cake day: December 6th, 2024

help-circle

  • That’s also my experience: there’s a certain generation of games, around 10 - 20 years old which have more likelihood of problems running in Linux than both older games and newer games.

    I suspect it’s partly to do with the kind of DRM used by AAA publishers back then - for example the Steam Windows version of The Sims 3 will simply not work in Linux but a pirated version will work fine with no tweakings needed whilst other AAA games from that era need a lot of tweaking to get to work in Linux.

    Meanwhile the most recent stuff just works with no need for tweaking.






  • Aceticon@lemmy.dbzer0.comtoMemes@sopuli.xyzWhat we all want deep down
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    1
    ·
    22 days ago

    This society deifies the crazy cat lady syndrome as long as it’s with money rather than cats and, worse, the actual crazy cat ladies are driven by good intentions whilst those obcessed with hoarding money are driven by almost the opposite kind of feeling.

    These people are literally sick people and the shitty system we have actually celebrates them and has laws designed to support the symptoms of their disease.


  • … and the amount of “set for life” money just keeps growing because we have to pay ever increasing amounts to rich people on things like housing.

    … and the safety of one’s savings keeps going down, so you can be “set for life” only for your savings to be wiped out because they exceed the bank deposite protection threshold or you had to invest it in some supposedly safe thing to generate enough interest to live of and it ends up pretty much stolen from you with no recourse (as many will find out when they finally try to draw on their private pensions).

    The system is rigged so that even being an entry-level millionaire is not enough.



  • I suspect that starting your own version of the API is the Software Designer / Software Architect version of Programmers’ “I know best so I’m going to do my part of the code my way which is different from everybody else’s”.

    Mind you, at the very least good Software Architects should know best, but sometimes people get the title without having the chops for it.







  • I’ve seen, again an again, deploying to Staging and integration testing in that Production-like environment together with the software of other teams, reveal problems that we did not saw in Dev, thus saving us from deploying into Production software that broke or, worse, corrupted the database.

    This was certainly very important when I worked in environments such as Investment Banking where Production being down because of integration issues or, worse, sending bad data to other systems or the database having to be rolled back to the overnight backup, might mean the business losing millions of dollars.

    It’s not a foolproof mechanism but it certainly catches most integration problems, which are often most of the problems in complex environments where multiple teams are responsible for multiple highly integrated software systems,

    Granted, little teams doing small software systems in simple environments were their software has little or no integration with other software, can probably get away with not having a Staging environment if their Dev environments has the same setup as Production (same OS, same database and so on) since they’re going to have very little in the way of Integration problems with other people’s software.




  • Personally I think it’s only much of a problem when it’s two languages from a language branch other than my native language.

    So, for example, as my native language is Portuguese (from the Romance branch) I have no trouble telling French from Portuguese, Italian or Spanish (even when words are the same the accent is different) and whilst I might on occasion mix Spanish words into Italian or vice-versa when speaking, it’s unsual, but when I learned German after having learned Dutch it was very confusing and almost felt like the German language knowledge was eating up the Dutch language knowledge in my mind, because one so often polluted the other one (more in the thinking and talking in that language, rather than spotting if the language spoken was Dutch or German, since the accents still give it away, to the point that I can tell Swiss German from that from Germany even though my German language knowledge is still pretty basic).

    Meanwhile back when I first I learned French after having learned English I never confused one with the other.

    I think that if you’re intimately familiar with a language branch you know enough to spot even small differences and know which is which or at least it’s a lot easier (hence I might confuse Spanish words with Italian ones - both foreign languages to me - but it’s unusual) but in a totally different language branch the “distance” from what is familiar is a lot larger and words from multiple languages from that branch which you’re not sure of just sound like they might be from any of those languages (or even multiple of them, which they sometimes are).


  • A family of software development processes for teams, which focuses on cycles of quickly building and delivering smaller blocks of program functionally (often just a single program feature - say: “search customers by last name” - or just part of a feature) to end-users so as to get quick feedback from those users of the software, which is then is use to determining what should be done for subsequent cycles.

    When done properly it addresses the issues of older software development processes (such as the Waterfall process) in siuations where the users don’t really have a detailed vision of what the software needs to do for them (which are the most usual situations unless the software just helps automates their present way of doing things) or there are frequent changes of what they need the software to do for them (i.e. they already use the software but frequently need new software features or tweaks to existing features).

    In my own career of over two decades I only ever seen it done properly maybe once or twice. The problem is that “doing Agile” became fashionable at a certain point maybe a decade ago and pretty much a requirement to have in one’s CV as a programmer, so you end up with lots of teams mindlessly “doing Agile” by doing some of the practices from Agile (say, the stand up meeting or paired programming) without including other practices and elements of the process (and adjusting them for their local situation) thus not achieving what that process is meant to achieve - essentially they don’t really understand it as a software development process which is more adequate for some situations and less for others and what it actually is supposed to achieve and how.

    (The most frequent things not being done are those around participation of the end-users of the software in evaluating what has been done in the last cycle, determining new features and feature tweaks for the next cycle and prioritizing them. The funny bit is that these are core parts of making Agile deliver its greatest benefits as a software development process, so basically most teams aren’t doing the part of Agile that actually makes it deliver superior results to most other methods).

    It doesn’t help that to really and fully get the purpose of Agile and how it achieves it, you generally need to be at the level of experience at which you’re looking at the actual process of making software (the kind of people with at least a decade of experience and titles like Software Architect) which, given how ageist a lot of the Industry is are pretty rare, so Agile is usually being done by “kids” in a monkey-sees-monkey-does way without understanding it as a process, hence why it, unsurprising, has by now gotten a bit of a bad name (as with everything, the right tool should be used for the right job).