There are lots of reasons why governments might desire to get rid of physical currency.

1. Crime - Physical money is the option of choice for criminals as it allows them to make off-record transactions so their activities are hard to trace

2. Tax - When otherwise legal business is conducted in cash, it’s possible for business income or employee pay to be undeclared or underreported, meaning the government is losing out on tax revenue. This is huge, and the gov really wants their slice of that cash.

3. Manufacturing and distribution - A minor point, but it is expensive to make physical currency, as well as to keep improving it to prevent forgeries and such. Getting rid of physical currency removes this problem.

I’m sure there are other reasons but those are what came to mind.

Despite these factors, any move to a fully cashless society is controversial, because not everyone is in a position where being fully digital is feasible. It has the worst effects on those who are already marginalised and disadvantaged in society, like the homeless, who may not even be able to open a bank account.

So I think it will be quite a long time until it might happen.

No, but his neighbours do.

There’s a few that would make good girls’ names when you think about it.

Ricotta

Fontina

Mozzarella (she goes by Ella, to her friends)

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.

I see the sculptor was flattering, and portayed him as in his younger and less chubby days.

Interestingly, British consumer rights guru Martin Lewis is currently running a crowdsourced data gathering exercise on this in the UK.

The purpose being to identify if companies are purposefully playing these sorts of message no matter their actual call volume. (Which we all know they are, but this will help prove it)

https://www.moneysavingexpert.com/report-high-call-volumes/

Subject: Job Application

From: pussyslayer420xxx@hotmail.com

Thanks for the confirmation that Buldak is, then, not really for me :)

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

I’ve basically decided to give up on Buldak.

I like spicy food, generally, but I ate the black one too and it was all spice and no taste.

I then tried one that was supposed to be cheese flavour (and not even the spicy cheese flavour, just regular normal cheese) and that was also somehow just spicy in a really boring way.

Seriously. Saw that in the cinema and couldn’t hear a word.

In part due to this, it has also become trendy and normalised to have bassy dialogue and lots of environmental noise, because that’s the expected “epic movie” feel.

So it’s almost become a self-fulfilling prophecy that movies will sound this way, regardless of the anticipated audio hardware.

Just another day on the job for pizza guy

You need a CD flap, and that’s the biggest visible feature of the console, so best to make it the centrepiece, and design around it. And CDs are circular so yeah, let’s follow that in the design.

You need two buttons, one for power and one for open. Symmetry is always appealing, so make them symmetrical and balanced on both sides.

Very much an example of “form follows function”

Yes, it absolutely is automated.

There are bots running constantly looking for things that match patterns for exploitable credentials in public commits.

AWS credentials

SSH keys

Crypto wallets

Bank card info

If you push secrets to a public github repo, they will be exploited almost immediately.