It’s pretty ridiculous.

What happens if you go there and Sony have moved their EULA page and it just 404s? Does that mean there is no EULA at all and you can play without terms? Doubt Sony woild see it that way lol.

EULA should be displayed within the same context it is accepted.

Not seen Nagato in a while

If a tree falls in the woods…

The teaser trailer looks like a high energy superhero romp that’s closer to Guardians of the Galaxy, than it is anything Star Trek.

And I just don’t like the idea that section 31 is made up of a bunch of oddballs and misfits with no discipline. Makes the movie more ‘exciting’ I guess, but really? Section 31 should move quietly in the shadows, not all brash and ballsy.

I’m sure they are hoping this style will boost revenue by appealing to a younger demographic, but it’s just totally the opposite of what I want from Star Trek.

Haha yep. Not the support process you want. Glad you managed to let them eat some humble pie at least.

The support process you want is this: “We’ll make you a channel on our Slack, if you’ve got any issues you can talk with our devs direct!” - yes please!

Any company that hides their documentation has an awful product that they are actually embarrassed about, from a tech perspective. They are hiding it because they are afraid to show it.

I’ve seen this so many times, and it’s a big red flag.

These companies work on the basis of selling their product the old-fashioned way, directly to management with sales-people and business presentations and firm handshakes, and then once you’re sold then developers (which management doesn’t care about by the way) have to do the odious task of getting everything working against their terrible and illogical API. And when you need help implementing, then your single point of contact is one grumpy-ass old dev working in a basement somewhere (because they don’t care about their own devs either) and he’s terribly overstretched due to the number of other customers he’s also trying to help, because their implementation is so shitty.

Conversely, public documentation is a great sign that companies took a developer-led approach to designing their solution, that it will be easy to implement, that they respect the devs within their own company, and they will also respect yours.

When I am asked to evaluate potential solutions for a problem, Public docs is like the number one thing I care about! It’s just that significant.

Side story - I once worked with one of these shitty vendors, and learned from a tech guy I’d made friends with that the whole company was basically out of office on a company-paid beach holiday - EXCEPT for the dev team. Management, sales, marketing, finance, they all got a company trip, but the tech peeps had to stay at home. Tells you everything you need to know about their management attitude towards tech.

You, SubjectNameHere, must be the pride of SubjectHometownHere

For added theatrics, after they pay you can slowly fade the site back in over a few days too, as if websites need bill money the same way humans need food, and it is slowly getting better after “being starved”

The fade should be slow and subtle. At first the client thinks they are just imagining it, but then they start getting customer support calls about the site being faded, and their bosses are pointing it out too in meetings, and as it happens more and more the panic really begins to set in.

Finally they reach out to you in a desperation when there’s barely anything left of the site and ask you to urgently fix the problem, and you just shrug your shoulders sympathetically and explain it’s happening because they haven’t paid - but not like in a way that suggests you are doing it on purpose, but a way where it’s simply an unavoidable natural consequence, like if you didn’t pay your electricity bill your power would get cut and the site is slowly “dying” and fading away because of that.

They’d pay so fast.

It’s good practice to run the deployment pipeline on a different server from the application host(s) so that the deployment instances can be kept private, unlike the public app hosts, and therefore can be better protected from external bad actors. It is also good practice because this separation of concerns means the deployment pipeline survives even if the app servers need to be torn down and reprovisioned.

Of course you will need some kind of agent running on the app servers to be able to receive the files, but that might be as simple as an SSH session for file transfer.

Yes, exactly that.

That’s probably okay! =) There’s some level of pragmatism, depending on the sort of project you’re working on.

If it’s a big app with lots of users, you should use automation because it helps reliability.

If there are lots of developers, you should use automation because it helps keep everyone organised and avoids human mistakes.

But if it’s a small thing with a few devs, or especially a personal project, it might be easier to do without :)

Sure, but having a hands-off pipeline for it which runs automatically is where the value is at.

Means that there’s predictability and control in what is being done, and once the pipeline is built it’s as easy as a single button press to release.

How many times when doing it manually have you been like “Oh shit, I just FTPd the WRONG STUFF up to production!” - I know I have. Or even worse you do that and don’t notice you did it.

Automation takes a lot of the risk out.

I’m sure there’s nothing wrong with the program at all =)

Modern webapp deployment approach is typically to have an automated continuous build and deployment pipeline triggered from source control, which deploys into a staging environment for testing, and then promotes the same precise tested artifacts to production. Probably all in the cloud too.

Compared to that, manually FTPing the files up to the server seems ridiculously antiquated, to the extent that newbies in the biz can’t even believe we ever did it that way. But it’s genuinely what we were all doing not so long ago.

Haha yeah, fair enough. Applogies for turning your deserved whinge into a serious question.

Wrangling annoying customers is always the most annoying part of the job isn’t it. How nice it would be to spend more time programming…

Technical requirements are often ambiguous when written as free text, the way someone would speak them, because as you have discovered the free text fails to capture where the linguistic stress would be that disambiguates in speech.

Instead, I suggest using a format that is more suited to text.

I would recommend a table. Email the customer back with your current interpretation of the requirements, with a column for outcome and a column for value. Ask them to check and sign off on the table, or to correct the table where it is wrong.

Example:

There are edge-cases with if outcome can be "Complete or Cncelled

This annoys me so badly.

I don’t drink carbonated beverages, so when I go into a place and don’t want beer then my options are basically coffee or water.

Fine in the mornings, but I don’t want a coffee at 5PM. So I guess it’s just water then huh

I’m pretty sure that a lot of these virus and malware scanners began as normal and well-intentioned businesses, and only later went bad.

I used to use Avast and AVG back in the day (like 10+ years ago) and they mostly just sat back and did what you’d expect, without being intrusive about it.

But of course the inevitable march of capitalism happens and they all start trying to make more and more money. Intimidating users with scare tactics. Aggressive pop-ups. Selling user data.

Wouldn’t go near them these days with a shitty stick.

My biggest problem is security updates.

The “x years of upgrades” model is okay when it’s for an app, where you can just keep using it with the old feature set and no harm is done.

But Unraid isn’t an app, it’s a whole operating system.

With this new licensing model, over time we will see many people sticking with old versions because they dont want to pay to renew - and then what happens when critical security vulnerabilities are found?

The question was already asked on the Unraid forum thread, and the answer from them on whether they would provide security updates for non-latest versions was basically “we don’t know” - due to how much effort they would need to spend to individually fix all those old versions, and the team size it would require.

It’s going to be a nightmare.

Any user who cares about good security practice is effectively going to be forced to pay to renew, because the alternative will be to leave yourself potentially vulnerable.

Yup, my comment mentions the parity disk :)

Good to emphasise that a bit more though.