Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
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.
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.
"You’re just a bad memory who doesn’t know when to go away" JR
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.
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
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.
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
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.
"You’re just a bad memory who doesn’t know when to go away" JR
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
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.
Comment