solraph

In metric, 19.2km of driving burns 4.5 litres of petrol?

Is that right? That seems absurdly high even for a large ute.

From memory (I haven't lived in NZ for a while now), the WoF check could be done at VTNZ stations, which explicitly did not do repairs to avoid this conflict of interest.

Alas, it looks like VTNZ was privatised and the exact outcome you would expect happened.

A set of tools to making setting up, joining and using a Samba domain on Linux much much easier.

This started with https://github.com/edward-murrell/sambervise - a GTK tool for admining Samba users and groups. I'm currently building a tool that walks a user through setting up a domain, adding DCs, and configuring fileservers and workstations.

In the TODO is making NFSv4 integration with Samba as painless as possible, and some kind of GUI application.

Done, for what it's worth. Krbtray doesn't have much in the way of a GUI to show though!

Good point, I'll do that.

I know how to write code, I just don't have time. AI has been an absolute game changer in let me get OS projects out into the world that I just didn't have time to build before. I'm having an absolute blast spinning up local GUI applications for Linux that I wanted to exist, but didn't have enough motivation to build before.

(Shameless plug)

* Sambervise: https://github.com/edward-murrell/sambervise - A Linux GUI application for remotely administering Samba 4 Active Directory Domain Controllers.

* Krbtray: A GTK3 system tray application for Kerberos ticket management on Linux Mint / Cinnamon (and other GTK environments using GtkStatusIcon, such as XFCE and MATE). https://github.com/edward-murrell/krbtray

If that is the entirety of their training regime, I will simultaneously be amazed and change my opinion.

However, I still maintain that if someone is _only_ doing 8 minutes of HIIT 3x times a week, it is not equivalent of a getting 150 minutes of regular exercise per week.

Without further context, it's impossible to comment further.

Fair enough, I don't think it changes my the conclusion though.

On that basis, I would say that someone whose entire exercise regime is doing HIIT a few times a week for 8 minutes (24 minutes in total) is not going to be hitting the 6x multipler required for an equivalent of regular 150 minutes of exercise.

tl;dr; Nope.

Assuming that HIIT workouts are 100% vigorous activity (unlikely), then a "few" instances would only add up to around 24 minutes of vigorous activity, which is far short of the minimum recommended 75 minutes of vigorous activity.

If you are short on time then performing HIIT for 15 minutes five days a week will get you much closer to the minimum requirements.

The paper indicated the Active group has doing at least 150 minutes of moderate-intensity physical activity throughout the week, or 75 minutes of high intensity activity activity (matching WHO guidelines[0]), and have done so for at least six months.

Anecdotally, I and several other people have found smart watches good for keeping track of intensity minutes.

[0] https://www.who.int/initiatives/behealthy/physical-activity

Any of the 1L PCs from Dell, HP, or Lenovo. They sip power (5~10 watts), and take up minimal space. I've got a 6 or 7 VMs running on one, and it barely breaks 5% CPU usage.

See https://www.servethehome.com/introducing-project-tinyminimic... for a good list of reviews.

Men aren't allowed to have male-only gyms but women do

Is that legally true? AFAICT, nobodies opening male-only gyms because there's no demand for them.

I guess it depends if you are after a club with men to help you climb some status ladder, or if you are after a club that helps you make male friends, regardless of where they come from.

I like the idea in general principle - but if I lived in the right city/country, and didn't already have something similar, my first thought based on the landing page pictures would be;

"This is only for white guys in their twenties."

I don't know if that's intentional, but if I was in the location target market, I'd close the tab at that point.

Not on laptops, which you'll be using if you are on call. It's even worse if you don't the eyes of a 20 something year old and have the text scaled up a bit.

periodic ragebait articles

Somewhat offtopic, but I call these articles "parading the idiot". Where a newspaper or other media outlet runs an article interviewing a person where the subject is clearly out of step with everyone else in their assumptions.

See also articles where a property investor complains about how hard they are doing financially because they have to sell one of their eighteen investment properties.

It's not an unreasonable proposition, but it doesn't explain why I'm seeing the exact same hiring trends in Australia, even before the USA election.

It's possible that AI may have some kind of impact on the industry too with respect to productivity, but I'd bet that it's nowhere near a 10-20% gain and it's not a factor at all in the difficulty of finding a job.

I'm not going to make any claim on the actual gain in productivity. My sample size of one for what was sometimes quite repetitive work is a very bad sample.

However, regardless of all other factors (let alone combined with them), I would say that AI has made getting a job far more difficult as AI gives people far more ability to shotgun every single job ad out there. I recently spoke to a recruiter who indicated that for a Senior Golang Dev role in Australia, he had received 400 applications. There is no-where near 400 spare senior Golang devs in this city.

I have found Copilot to be useful enough to use if someone else pays for it. In some cases it was useful (writing Golang functions that perform basic SQL CRUD functions). Others times, not so much.

As I said above, I'm not claiming it's a massive increase, only that it is there. If AI moved the productivity needle 2%, and a given market has 100,000 software engineers, then that's possibly 2000 devs that are spamming the heck out of every job out there.

Either it's complete PR BS (most likely), or C-level execs are putting the cart before the horse - preparing for "productivity gains" that haven't actually materialized.

All of the above is also a real possibility.

My take for SE roles is that it's a combination of AI giving enough gains[0] to reduce head count requirements, combined with the higher interest rates cutting off the tap of free money for startups that never really made economic sense.

There's also the absolute flood of CS graduates in recent years contributing to the number of applicants. I know governments have been screaming for more STEM graduates, but I suspect the numbers are far higher than what is actually required.

IMHO, the outcome of all this is that those devs who can't actually code are going to be pushed out of the SE market, and things will normalise in 12-36 months.

(I say this all this sitting on the couch waiting for the results of second of three interviews after submitting my 30th application - I've literally never had to submit more than five - and that was where I didn't get poached directly.)

[0] I'm not going to say it's a _massive_ gain, but even a 10-20% increase in productivity from something off the shelf like Github Co-pilot would show up in employment numbers

Even for the most heinous crimes, the death penalty has one massive glaring practical problem.

What if the sentenced person is actually innocent? No amount of apologies or recompensation will bring that person back.

I had this issue with my Lenovo laptop that shipped with Ubuntu and some Broadcom piece of rubbish wifi that also broke the crap out of sleep mode.

The solution was to buy a $40 Intel Wifi card and swap it out. I haven't thought about Wifi since, it "just works".

I agree with most of this list, and I'd add some kind of null coalescing or ternary operator, even if it was limited to one operater per expression, and a date time handling library that doesn't make me want to pull.my hair out.

There's several things that keep me on Go, single binary, decent built in tooling, and decent speed.

I've started playing around with tinygo on Pi Pico's, and after the dealing with getting C and C++ onto other MCUs it's a breath of fresh air.

But the rough edges are very rough. At some point another language is going to come along with better syntax with the same single binary and good tooling and I'll probably switch over as fast as possible.

Without knowing anything about the system at all - does it use the same payment system as the buses?

Alongside the other reasons mentioned (comfort, right of ways, dedicated corridors), it's blatantly obvious where trams run due to the tracks in the ground.

With a bus, there's always the potential the route has changed, or your specific bus is skipping over your stop for some reason. With a tram, even if you've never been to that city or part of the city before, you know there's going to be a tram along those tracks, and you simply need to walk along the road till you find the stop.

I've run various meetups in the past, some of which have been successful, some not.

The biggest thing I learned was that you if you start it, you have to drive it. If you take a few months off, don't expect anyone else to pick it up and run with it, even if they offer and you give them the keys to do so.

Nowadays I don't have time for anything too involved. Instead of meetup.com, I "run" a small private group (which is me with a mailing list and a google calendar invite) of remote IT workers in Inner North Melbourne (AU) who catch up for beers once a month (email in my profile for details) It's surprisingly better in some ways. The group is tighter, and there's far less stress.

Usually any given country will have one big spot for tech... ...My guess is that Melbourne is not a very good spot.

It's not an unreasonable assumption, but in this case it's incorrect. Sydney has more tech work, but only in proportion to its larger size.

That said, Melbourne tech work is very heavily (but not exclusively) orientated around finance, insurance, real estate and so on which is not everyone's cup of tea.

They can be a bit of a pain, but if you have a lot of logic tied up in your external dependencies (SQL usually bring main offender here) it's not possible to properly test without using said dependency.

That said, in the current job, we have a dedicated Postgres container that comes up with with a just file command. The setup, test, and teardown of schema all happen within the standard test system of the tested platform (pytest or go test specifically).

I've never been a fan of TDD and personally I think tests that really hit your DB, Redis, etc. help a lot more than mocked out unit tests or a billion unit tests and nothing else... ...but I do really write to the DB and other data stores in tests

I've come to the conclusion that the idea that "unit tests" should test functions/objects in isolation with completely mocked dependencies is based more on the slow speed of those dependencies in the past than what actually makes for good tests. Now that we have faster computers and storage devices, and easy/fast store creation, we should move past this.

Obviously, this is very dependant (no pun intended) on the dependency in question, but as a minimum, anything with SQL should have a test that hits a real SQL DB (PG in docker for example) at some point.

> Even with good design, w/o tests you will fear change and so the code will rot. With good tests, there’s no fear, so you’ll clean the code

Has anyone ever actually found this to be true?

Yes, but you have to have the right kind of test coverage, and that's the tricky part.

Yesterday, I refactored a bunch of functions that changed a bunch of unit tests. However, since we also have integration/system tests on that code, I'm confident that I haven't broken the code as a whole. Without those system tests, I would not have confidence that the change would be successful, and probably would not have refactored.

In another codebase that hadn't been touched for a year, as part of a feature change I refactored an SQL statement to what I thought was a more optimal design and immediately broke a bunch of tests. Based on that, I was able to understand the original intent of the SQL, and updated it in line with the feature change. I added test scenarios for the new feature, but left the existing scenarios as is.

Without those tests, would have broken the system in a subtle way.