test please delete

[BrilloPad]

A WFH mandated fish finger butty is on the go. I've also managed to squeeze in a trip to Aldi to grab some kids skiing gear, half of which will have to be returned depending on sizes. Oh, and some coal, since the coal shop was close by and open. They were doing brisk trade it must be said.

Barry - exactly what is the "it" that you did?

[BR14]

Barry - exactly what is the "it" that you did?

Ate all the fish fingers.

[SueEllen]

A WFH mandated fish finger butty is on the go. I've also managed to squeeze in a trip to Aldi to grab some kids skiing gear, half of which will have to be returned depending on sizes. Oh, and some coal, since the coal shop was close by and open. They were doing brisk trade it must be said.

The trick with Aldi is to get the phone app and see what is likely to be online the week before.

Get up on the Sunday morning and order it online.

Then return it if half of it doesn't fit.

[MrMarkyMark]

A WFH mandated fish finger butty is on the go. I've also managed to squeeze in a trip to Aldi to grab some kids skiing gear, half of which will have to be returned depending on sizes. Oh, and some coal, since the coal shop was close by and open. They were doing brisk trade it must be said.

I didn't realise you were a midget

[NickFitz]

Home, and weekend!

Snow (possibly sleet) from the Kettering bypass, getting quite heavy around the Mighty Windmills of Kelmarsh, then fading out near the M1; but then again, though light, coming up the final stretch of the Fosse Way before home

[NickFitz]

While they were in the all-hands meeting this morning, I was mucking around trying to deal with a local database whose schema was seriously at variance with that reflected in the migrations on the rather old Git branch on which I needed to do something. Eventually I decided to just blow the thing away and start again from scratch. I tried dropping it from PyCharm's database window, but then that got confused because it couldn't connect to a now-non-existent schema.

So I opened up a command line, ran the mysql client, and dropped and re-created the database.

Switching back to PyCharm, the GUI-based database client stubbornly insisted there was no database to connect to.

So back to the command line to try to diagnose what was wrong… where it suddenly became apparent.

Way back before I started there, they had the foolish notion that all the devs should work off the same database server and, even more foolishly, set this up by sticking the connection details in the /etc/my.cnf file on our workstations (actually Linux VMs). So when I ran mysql without specifying a host, rather than connecting to localhost by default, it had connected to the dev database server.

And just last night, they'd set that up with a pristine copy of data they wanted to use for testing a bunch of stuff - a process which, due to some tables having unutterably huge amounts of data, takes all night to run.

And I'd just dropped the lot

And this is why:

They very sensibly keep me away from the place where people deal with the actual running of the data centres and such, as there's no need for me to have anything to do with that and I'd probably just break everything by trying something out while logged in with the wrong account

[SueEllen]

Way back before I started there, they had the foolish notion that all the devs should work off the same database server and, even more foolishly, set this up by sticking the connection details in the /etc/my.cnf file on our workstations (actually Linux VMs). So when I ran mysql without specifying a host, rather than connecting to localhost by default, it had connected to the dev database server.

<snip>

What feckwits.

[NickFitz]

What feckwits.

I particularly like the business of putting the credentials in /etc/my.cnf so the default host/username/password are all completely different to what you'd expect, too

In fact, they aren't even in my.cnf - they're hidden in a file in /etc/my.cnf.d/ that's then included by my.cnf so it's not obvious even if you do look there first.

The first thing I did after realising what had happened was to edit that damn file, with vim no less, and comment all that stuff out

[BR14]

While they were in the all-hands meeting this morning, I was mucking around trying to deal with a local database whose schema was seriously at variance with that reflected in the migrations on the rather old Git branch on which I needed to do something. Eventually I decided to just blow the thing away and start again from scratch. I tried dropping it from PyCharm's database window, but then that got confused because it couldn't connect to a now-non-existent schema.

So I opened up a command line, ran the mysql client, and dropped and re-created the database.

Switching back to PyCharm, the GUI-based database client stubbornly insisted there was no database to connect to.

So back to the command line to try to diagnose what was wrong… where it suddenly became apparent.

Way back before I started there, they had the foolish notion that all the devs should work off the same database server and, even more foolishly, set this up by sticking the connection details in the /etc/my.cnf file on our workstations (actually Linux VMs). So when I ran mysql without specifying a host, rather than connecting to localhost by default, it had connected to the dev database server.

And just last night, they'd set that up with a pristine copy of data they wanted to use for testing a bunch of stuff - a process which, due to some tables having unutterably huge amounts of data, takes all night to run.

And I'd just dropped the lot

And this is why:

there's a technical term for that.
it's Z/oops

[NickFitz]

Fish fingers, chips, and beans for dinner; because I'm worth it