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;

  DELETE FROM userSessions WHERE id=123;

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.

This brings back a memory of when I was given the only copy of an XML file that was large data extract that needed to be restored. Unfortunately, somewhere along the lines the XML file had been corrupted in a way that broke most XML parsers of the time.

At the end of the day I had a Perl script that used a regex to extract each top level element in the XML, which it then could attempt to parse. If the element parsed correctly then it was put in known good file and if it didn't parse then it was put in it's own separate file. Luckily there was only a handful of those invalid XML elements, which I could fix up by hand and then stitch back into the known good XML file.

Personally I prefer to be sent a full email thread over a message in chat, because

a) I can ignore it until I have time to look at it

b) You can see who else has already been involved in the conversation - seeing a fellow team member being involved can help avoid falling for situations where someone is trying to work around one of your colleagues who's already told them they can't have what they're asking for.

c) The chat message is from an individual, so you only get their interpretation of what's happening - if there's an email thread then there's going to be multiple people involved, each with their own perspective.

For anyone interested in this I can recommend the book, The Future Was Here. It really explains the Amiga hardware and how it was used. It even goes into how the bouncing ball demo works, and once you know all the tricks it could use on the Amiga, you can see why other computers of the time had to work so hard to recreate it.

I hope you responded with "The team is still learning, which is exactly why I shouldn't be quiet about code standards."

One of the many definitions of the word Render is "to cause someone or something to be in a particular state", another is "to change words into a different language or form". Based on that surely a web server is rendering data to HTML, or JSON, or plain text. It's still rendering even though it's a lot easier than the work the browser does to render HTML to graphics.

I don't tend to use Caps Lock at all - I know a lot of people remap it to be escape, just like OuterVale has mentioned, but for me it's just a key that I never use. Then again I no longer use home, end, page up and page down keys either - I switched to a split keyboard that doesn't have them as separate keys and you need to press a Fn key with another key to get them and as I live in the terminal for all my real work I just switched to using the CTRL key combinations instead.

Which, to me, heavily implies that you should be taking all feedback as being valid with your best interests in mind. My point is that feedback isn't always valid and sometimes you need to reject it, as accepting it can also mean that you're also accepting something that you don't want (usually blame for someone else's mistake).

So for example, you get feedback from someone that your API to delete users was badly designed because a bug in their untested script called it on 100 high profile users accounts and it deleted them. You don't accept that feedback, you push back and ask why their script called an API to delete users for 100 users that they didn't want to delete - if you just accept the feedback without pushing back then they can legitimately say to their manager that you've admitted that the fault was with your API and not with their development practices.

I don’t care how smart or ahead you are, but hard work always beats talent.

Although you do need some talent or working hard will just be making problems for everyone else, and all management will hear about is you being the cause of problems rather than a solution to them.

Be Open to all feedback

Actually I'd suggest people don't just accept all feedback - before taking any feedback on board review it and see how it holds up. There's a lot of people out there that will give negative feedback, not because it's true, but for other reasons (e.g. it makes them look better to an onlooker, it pushes blame for a failure away from their team and onto yours, they're just an a**ole).

You know that you can just press <CTRL+D> at the bash prompt to quit it as well? (In fact <CTRL+D> will quit out of most command line programs as it's the End Of Transmission character)

`cd -` is great for when you just want to nip out of your current directory for a second and then come straight back - especially as I'm pretty sure that most of us never think about pushd/popd until after we've moved to the other directory with cd :)

Find's -exec option is great when you need to automate removing old backups

This one gets uses a lot to compare two versions a JSON file

  vimdiff <( jq < /tmp/file1.json ) <( jq < /tmp/file2.json )

Prometheus fronted by grafana is great and I use it a lot for work, but I can understand why they don't want to deal with it for just monitoring their home network - and writing your own monitoring software can certainly help you appreciate what you get from Prometheus.

Starting with a program in memory would require that program to have been in ROM and then loaded into RAM on boot, but space in ROM was at a premium back in those days. However machines of that era did the next best thing, they provided some of the best computer manuals ever which focused on the use of BASIC and had plenty of examples for people to type in and play with.

Also the magazines back then had listings that you could type in (and usually then debug). They even had columns where you could write in with your problems and one of their "Experts" would provide some help or advice in a future issue. Yes you did have to wait a couple of months to see your answer in print, but seeing other people's solutions to other people's problems really helped.

I couldn't get through this - I suspect it's because I decided a long time ago to make the effort to stop thinking of programming paradigm's as any one language, and instead to think of them in more abstract terms. That's really helped me to know when one paradigm or another would be better for the task at hand (There are tasks that are easier to think about from an OOP perspective and others that are easier to use a functional or imperative approach).