I have seen various attempts at turning live sports into some form of 3D rendered animation. This is usually an attempt to coax younger viewers into watching sport they may previously not have been interested in. The most recent one I've seen is the Simpsons NFL game from about a month ago.
But what is interesting about the Australian Open approach is that they are using it to get around rights issues, allowing them to broadcast full matches live globally via Youtube, with commentary and audio from the courts.
This is despite the large pot of money they have made from selling broadcast rights to TV channels across the globe.
If I was one of those channels, I am not too sure I would be very happy about this, especially as it is proving to be quite popular.
The technology is not perfect, it can be a little glitchy with the backgrounds and the players. But at times, especially with all the angles, it is easy to forget they are not real.
There has to be a limit here though. If the technology keeps improving and can render ever more realistic players, at what point do they break their broadcast contracts? Do they ever? Photorealistic rendering does not seem out of the realm of possibility even now, so does that mean they are deliberately keeping it cartoony to not dip into that even greyer area?
If you cannot find what to watch on streaming services, but you have a bunch of your own media, like Youtube downloads or DVD rips, then you may be interested in creating your own local IPTV channels.
I have been experimenting lately with ErsatzTV, a Github project which you self host and can connect to your Emby, Jellyfin and Plex servers to retrieve media, or can simply read it off the local file system.
You can create schedules of programming with more options than I can honestly currently understand, then create playouts of these schedules onto channels. Each channel can have a name and even a watermark in the corner. If you are really adventurous, you can even populate the spots between your programming so everything correctly starts on the half hour or hour. I've seen some impressive examples of recreating mid-80's and 90's television with period appropriate bumpers and breaks.
Once you are done, it can publish M3U and XMLTV feeds for you. These should be usable in a lot of different IPTV software apps, but I am using Plex with the DVR support. Each of my "fake" channels appears in Plex and I can "tune" into them and see what is currently playing.
I am still learning what is possible, but tuning into my music video channel is a good way to have something on in the background while working.
I have been doing web development for a long time. In the early days that meant editing HTML without CSS, just font tags and animated gifs in Notepad, uploaded via FTP to my ISP provided "web space".
Web pages were basic and very simple to construct. I learned HTML through experimentation and "view source" along with millions of others.
There were few tools to choose from, no web server software to worry about, and it was mostly a game of making sure your page rendered correctly in each browser as new ones were released.
In the 28 years since there has been a web development explosion . There are a million tools, too many frameworks, a thousand different ways to approach and solve every problem.
I have tried a small fraction of the available options, yet have the battle scars of what worked and did not work during those years. That means for every new project I try and start, I am crippled by that experience.
I do not have the unbridled optimism or naive outlook of a new developer who has never tried anything before. The young upstart at school or college trying downloading node for the first time, getting their first Python function working, or wondering why there is so many things to learn before you can even write a line of code.
Instead my brain sees nothing but problems. The function that will not scale properly. The server configuration that works now, but which offers no high availability. The dependency tree which is not pinning any versions, so is just one npm attack away from oblivion.
Of course it is not always that straightforward. It may not be good, if it is not fast. And it may only be possible to make it fast at the expense of making it good.
But that does not mean it is not a useful way to describe the process to someone who is not experienced in the suffering of the average software developer.
What is often missing in the explanation to the non-experienced manager is that the time between each of those steps may be double the previous.
Imagine a form where a user is going to enter a delivery address.
A basic working version may have all the necessary fields, a name, a couple of generic address fields, perhaps a city, county, postcode and country. It will save to the database on submission.
But making it good and making it fast require significantly more effort. Addresses are complex. Maybe some form of postcode search or global address autocomplete would be better, but that's a big database to manage yourself. Validation sounds easy, but not every country has postcodes. And even searching for your country in a list is a pain if you have to scroll through a lot of them just to find the United Kingdom. Perhaps the most common countries that use your website should go at the top.
There's lots of little decisions that make it good. And some skilled technical know-how to make it fast.
When you want me to estimate something, is it just to make it work? Or do you want it to be good? And if you want it to be fast, then how long have you got?
It may take a week to make the feature work. Two weeks to make it good. And four weeks to make it fast.
The quality of a software product is often determined by which of those the manager is willing to bear.
And the quality of a software developer is often determined by how much they care about making it good.
I don't have many problems with WiFi (I use an Asus RT-AX82U). But for my Synology and other mini PCs mentioned earlier, it's just better if they're on Ethernet. But despite my best efforts while they were building our house, the builders wouldn't put Ethernet cable in for me, so I must resort to retrofitting.
As I'm trying to avoid drilling holes in all my walls and ceilings, I first turned to Powerline adapters. But despite trying three different models from different suppliers, none of them worked reliably, especially across different floors of my house. This was the case in my previous house too, they just never work for me.
But like most new-build houses in the UK (our house is 8 years old), I have old-fashioned RF aerial sockets in each of the rooms, all of which go to an aerial booster in the loft. This is so I can receive over-the-air television, also known as Freeview in the UK.
After a bunch of hunting, I discovered this goCoax MoCA 2.5 Adapter (sold out as I write this). MoCA is known as "Multimedia Over Coax", which is a very American sounding protocol for sending ethernet over existing coax cabling. I bought two of these and installed one downstairs attached to my router and plugged into the aerial socket behind my TV, and the other one upstairs in my office. Along with a little Netgear Switch, it has allowed me to extend my network with minimal of effort.
I do have an aerial booster in the loft, so I did switch that off. I don't have any TV's plugged into the aerial sockets anyway, because my kids don't know what linear TV is. I'm not 100% sure if this is necessary, but I found some advice online that it was, and I did have some additional difficulty getting things to connect.
It's been 4 months since I installed this and it has been 100% reliable. No drilling required. I just wish there was an aerial socket in my garage and I could extend it further.