nvella

This is happening right now, on a massive scale in Australia's NEM (National Electricity Market). Our market operator has recently moved to five minute pricing and settlement windows to accommodate the rapidly changing energy mix throughout the day, as well as rooftop solar; lots of it.

Most rooftop solar installations were installed before home batteries and smart inverters were common, so the market often finds itself in negative pricing during the day, incentivising investment into grid-scale batteries and pumped hydro which can be paid for both storing the excess during the day, and exporting it in the evening peak. Recently, as home batteries and smart inverters have started to become more accessible for home-owners, it is common to join your household onto a 'virtual power plant' with your electricity retailer, who then commands your household battery alongside thousands of others as similar to this article and pays a credit onto your bill. The other interesting development has been the wholesale pricing retailer; not only do they apply the live wholesale price to your consumption, but also your feed in. I know one of them (Amber) can connect into your battery and drive it's charging/discharging in response to the market price. It's not been uncommon to hear people's bills ending up in credit as the capacity of their battery, combined with the price volatility far outweighs the price impact from their consumption.

The volatility poses its own challenges however. Traditional retailers which typically provide flat or peak/off-peak rate have been struggling to economically provide competitive feed-in tariffs to their customers with older roof-top solar systems; systems which are unaware of the pricing environment. Many of their customers have these solar systems which export straight into negative pricing, creating a loss for the retailer that they have to somehow recoup. As far as I understand, they can't legally have a negative solar feed-in tariff, so I assume they're shifting the loss to the consumption tariff. Even though our daytime prices are often below $0/MWh, the average Australian will tell you that their electricity bill is the most expensive it's ever been.

I've only read the abstract, but hasn't this been achievable for at-least the last twenty years with dependency injection? I've seen time and time again developers conflate microservices with the general concept of service abstraction and separation-of-concerns. These things have existed before microservices, and will continue to exist.

A good DI implementation allows for one to define these business services as interfaces and implementations within an initial monolith, and then trivially reimplement those interfaces against an API or RPC when it comes time to scale. Interfaces can be separated out into a common library which can be referenced in all parts of the system. I am simply curious as to why this has been so staunchly avoided over the past decade of microservices hype.

The concern is not really around disk but memory, opening just a few Electron app instances is enough to bring a machine with 8GB of RAM to its knees. I’m almost convinced that this is some kind of a planned obsolescence plot.

A standard interface for web views would be great, I’d love to force everything onto a consistent version of Gecko, but really we need a new native cross-platform batteries-included framework with controls and layouts for 90% of standard business scenarios.

From lived experience, creating a cross-platform application via abstracting the relevant native interfaces versus targeting web with all the _fun_ that entails are effectively equal levels of pain. Developing rich web apps isn’t free either; I needn’t go into the issues surrounding the revolving door of frameworks, contrived state management patterns that seem to change every year, the total lack of standard controls outside of built-in web elements that look awful which inevitably means that at some point, _you will_ have to be doing DOM manipulation for something that is otherwise built-in on an OS’s native toolkit, etc etc. And then when you put all of this together, you add yet another 500MB Chromium instance onto your user’s desktop and the thing feels like a social networking app.

I’m not going to pretend that there’s currently a better solution because for the current set of constraints everything sucks. .NET has a few up-and-coming frameworks for cross-platform UI but nothing mature like WPF was. Java still produces noticeably slow applications. React Native could perhaps get part of the way there, but as far as I’m aware that mostly targets mobile.

I remember reading this site so much when I was eight years old. It's been around for at least sixteen years. Glad to see its still up, looks exactly the same too.

There was a similar installation at the Australian Centre for the Moving Image, Melbourne in 2015. Not sure if it’s still there, at least when I was there last it emailed your video in FLV so I gather the setup was pretty dated.

Not sure how different things are in other parts of the world, but here in Australia all of our debit cards are on the regular Visa/Mastercard networks; you can use them wherever you can use a credit card online. It's just the transaction is likely to decline if you don't have a balance in your account.

This is pretty cool! It immediately reminded me of Gary Bernhardt's 2014 talk, 'The Birth and Death of Javascript'[1]. Truly life imitating art.

[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...

I actually find the metaphor quite useful–as a developer I can develop a GUI application utilizing a common menu metaphor but _not_ always have a window open; essentially an application is a 'toolbox', presenting its tools via the global menu, and documents/'work' appear as windows. For context, I used Windows all my life before switching to Mac about six years ago, and I find this makes a lot more sense than one menu per window, where application developers often like to go their own way and implement their own menu metaphors.

Before the inevitable comments regarding Apple's moves with macOS and how the hacker 'tide' is supposedly turning back against Apple, I think I'll chime in with my two cents. I switched from my 2015 MBP to a Surface Book 2 at the end of 2019, and switched back to my same, six-year-old MBP just a few months ago. To keep things short, whilst WSL puts Windows miles ahead of where it once was, I find that the same old rough-edges still remain.

I often dock between standard-DPI displays and portable mode (with the high-DPI/'retina' display.) I first noticed that Windows doesn't correctly handle DPI switching with window borders, Explorer, and notifications back in 2019 (the old 2x scaling level remains when switching from portable to docked), and filed a feedback with the built-in app on Windows. I worked around this by killing dwm.exe and explorer.exe every time I docked my Surface. This issue was still present earlier this year, and deciding I had enough of dealing with all these little Windows 'quirks', wherever they arose, I switched back to my old Mac.

It turns out that SIP and Gatekeeper aren't nearly as much of a problem as I was led to believe, neither of these features have hampered me once. The Big Sur interface changes, whilst I thought I'd never get used to them, have actually grown on me. Since switching back, I've discovered a lot of quality native apps that simply have no analog on Windows–OmniFocus stands out here. And as always, Homebrew still exists and works just as well as it always has for most of my *nix related tasks.

Hearing about the M1 performance improvements, I can see myself staying on Mac for quite some time yet–I'll upgrade to an M1 MacBook Air once this 2015 MBP (six years old!) kicks the bucket.

Edit: For some context, I'm mainly a .NET developer. .NET Core/5 is a game-changer for cross-platform and development is first class on really any system nowadays. I've settled on JetBrains Rider for my IDE and find myself generally happier than I was with VS on Windows.

Cheers :) Yeah, I was one of those kids that spent most of their free time programming or otherwise tinkering with computers. I started with simple systems scripting languages before moving to Ruby and getting a proper grip on basic OOP stuff, C then shortly followed.

I don't really have any use for C today, but it definitely taught me a lot. It was intimidating at first, but when the concept of pointers finally clicked I felt like I had a sense of control in the language, and things were relatively deterministic and predictable.

I did most of my projects in C for a few years, but eventually got sucked into the JS ecosystem like pretty much everyone else at the time. These days I mostly work in .NET - C# is constantly evolving, and with .NET Core it's seemed to strike a good balance between powerful tooling, cross-platform support, performance, and just fun language features. I'm pretty content for now :)

I must say, out of all the things to happen on a Thursday night I wouldn't have expected to read an article where someone referenced my own code that I wrote when I was 15. (5 years ago now... time flies) Here's the file I presumed he looked at; https://github.com/nvella/sdvr/blob/master/pk.c

I was trying to reverse-engineer my parent's network CCTV DVR so I could hopefully integrate it with Home Assistant - as far as I'm aware the sluggish smartphone apps are still the only way to access those boxes. I wasn't ever able to get as far as George did with his IP cameras; I hit a snag on trying to correctly reassemble the H264 streams, so all I ever got out of it was mostly corrupt still frames.

If you're reading this George, well done! :D