scrapheap

When I first read The Time Machine (by H.G.Wells) I wondered how the split between Eloi and Morlocks happened, and where in the timeline it started. The more I see of people using AI leads me to wonder if perhaps that split started a lot sooner in the timeline than I expected.

Or to put it another way, if you push everything into the AI, then you going to become entirely dependent on those people who can keep the AIs running...

In fact, I don't think I've ever heard the term "clean eating" used before... I wonder where that term is commonly used?

That fear is good, it means you know that you're taking a risk - I'd worry if you had to touch production and didn't feel that fear.

If you only have the one or two production systems/databases, and you're having to do this more than a couple of times each year, then you could certainly benefit for improving your tooling.

But if you've inherited a large number of production systems, each with their own local database instance. Then implementing new tooling will be a long process that you might not be able to get Management to agree to.

When I have to touch a production database, I usually use the following steps:

0. Follow your organisation's Change Processes (i.e. if you need to put in a change request and get approval then do that)

1. Snapshot the server itself (VMs are great for this)

2. Backup the database (just be careful not to leave that backup anywhere open, and remember to clear it up when you no longer need it)

3. Write the SELECT version of your SQL first (If you need to delete a record from the userSessions table with an ID of 123, then start by writing

  SELECT * FROM userSessions WHERE id=123;

4. If that shows you just the rows you'd expect then convert it to the delete from of the SQL (making sure that you don't change any part of the WHERE clause)

  DELETE FROM userSessions WHERE id=123;

5. Get someone else, who also understands the database, to check your SQL

6. Run your SQL

7. Do all your sanity checks to make sure that production is working as expected.

8. If it does go wrong then you have more ammunition to use when trying to convince Management to spend some resources on improving your tooling for these sort of changes.

My personal opinion is that if a team couldn't write something before AI then they should be very careful about writing it with the help of AI.

For example a team that couldn't write a new encrypted messaging app without AI, gets an AI to write them one. How do they check that the code is actually secure? Writing encryption code is very hard to get correct, in fact most humans can't get it right, and if you don't understand the intricacies of cryptography then you'll never pick up the mistakes the AI makes.

Yep, it's a shame that we keep making the same mistakes when it comes to basic security practices.

200MB for a desktop sounds massive to some of us :D

Back in the day I used to have a desktop running, with applications, in just 512KB. Getting that memory upgrade to a full 1MB was amazing.

It always amazes me the number of SaaS solutions that don't implement rate limiting, then tell us not to worry about it when we ask how hard we can hit their APIs, and then complain that we're hitting their API too hard.

My favourite response from one of a suppliers who hadn't implemented rate limiting was "Please stop, you're making our database cry" :D

You can get light spreader kits for the F91-W/A158W that replace the bit of plastic that sits behind the LCD for one that spreads the light from the LED far more evenly than the stock one.

I recently fitted one on my F91-W and it certainly makes a difference, but it's not going to make the light brighter like some of the other LED mods people have done.

As a team we use Kanban, so everything being worked on gets a ticket and we walk the Kanban board every morning. So if a task is waiting for someone to review it, then it gets highlighted to the whole team each morning. If a task is blocked until something else happens then it gets highlighted to the whole team.

Walking the board feels a bit awkward and slow at first, but after a few weeks you find that it takes very little time. It certainly works well for us.

Where possible automate them!

From my point of view the power of automation for recurring tasks is less to do with time saved, and more to do with making sure that it will get done and be done the same way every time.

Bonus tip: log the outputs of automated tasks when they run, but only send out notifications of errors - that way you don't train staff to ignore the notifications from the task just because they see it every time the job runs, and instead seeing a notification from it is rare, so they know they need to investigate.

That is the second year of a PhD - the first year you're distracted by your literature survey of the area you're interested in. The second year is where you're trying to dig out a little niche that you can work in and expand the knowledge of what's there. The third year is where you're supposed to be writing up, but in reality you're probably still working on building up enough new knowledge in the area to actually write up.

It's not uncommon to feel the way you are during the second and third years - my advice is to recognise how you're feeling and then work out how to push forward (which is what you've already started to do).

My advice for how you can compete with large research projects full of postdocs is, don't try to. You're not in competition with them, you are doing your own research. It might be in a tiny niche area, but it's your area and it's new knowledge.

Stand out books for me that I've read this year:

* The Tusks of Extinction by Ray Nayler (Short, but a great read)

* The Incandescent by Emily Tesh

* The Armchair Universe by A.K.Dewdney (First read this one many years ago, but I've been reading it again)

* Final Orbit by Chris Hadfield (third book in a series, so you'd want to start at the begining with The Apollo Murders)

Interestingly that would put some UK banks as running code that was written when the currency was still Pounds, Shillings and Pence.

In the past I've heard that some banks put a decimalisation layer on top of their existing business logic, that would translate between the old Pounds, Shillings and Pence currency, and the new decimal currency. I wonder if there are any banks out there which still have Pounds, Shillings and Pence at the heart of the computer systems.

Tags and Stashes are both commonly used features of Git. There's a lot of value of having well defined ways of handling them, especially when it comes to collaborating with others on developing code.

With the way Stashes are implemented, you don't have to worry about someone accidentally pushing a branch up that was really just some changes they wanted to store temporarily without messing up the repository's history.

With the way Tags are implemented, you don't have to have an agreement with all your colleagues about how a branch should be named to represent a tag. You also don't have to worry about how you have named the branch you're working on that will add support to your current project for it's own concept of tagging.

A web version of comm, I can see that being useful for a lot of people who don't want (or know how) to use the command line.