Yes; many (Alpine/Debian) containers in K8s on GKE for production rail ticketing infra in the UK.
There's not tons of noise being made because for the most part it all, Just Works and that's fairly boring. Perf, memory usage etc gets better every release. As an ecosystem, I'm pretty happy with it. I reach for other languages for smaller microservices.
> The alternative would be that each school develop their own platform for this
I worked at a university which did exactly this, in the UK.
It was a bespoke platform which integrated incredibly well with the rest of the systems the university used because it was designed from the ground-up to meet the institution's needs, there were regular user groups involving academics to understand what features needed to be built/worked on etc. At one point it was all OSS on GitHub too, in case other universities could've found it useful. It handled plagiarism detection (integrating with Turnitin), marking, exam grids, coursework submissions and feedback, seminar allocations, personalised timetables & mitigating circumstances.
The in-house dev team was vastly cheaper than anything SaaS would've cost, as well. It also maintained software for on-campus parcel deliveries, online exams, opinion surveys, a mobile app for students/staff, the SSO system, the course catalogue, car parking permits, a content management system and more.
My (also UK-based) university has been working on a new student records management project for years that's been incredibly ill-fated. It's destined to replace all their current systems and the first module module was meant to launch last year, except it thoroughly failed testing and nobody has heard anything about it since.
No idea how long it'll take to pull through. I don't believe it's an in-house effort.
In-house bespoke software sounds reasonable, and multi-customer SaaS sounds reasonable, but outsourced bespoke software sounds like a complete dumpster fire:
End users who report problems:
* are ok with IT level 1 telling them IT level 3 is working on it with velocity appropriate to keep their jobs,
* are ok with IT level 1 telling them ${vendor_of_well-known_solution} is working on it with velocity appropriate for many customers, but
* are not ok with IT level 1 telling them ${vendor_of_bespoke_solutions} is working on it with velocity appropriate for one customer (if they even still exist).
They already prevent advertising the sorts of foods that contribute to obesity to children, and encourage you to drink less sugary drinks by applying tax to them (though unfortunately manufacturers have responded to this by reducing choice and adding artificial sweeteners instead of selling something at a higher price that can be enjoyed once every few weeks.
I don't think any of this is unreasonable in a country that picks up the tab through both subsidised dental care and completely free-at-point-of-use healthcare.
A legislation that isn't possible to enforce is not reasonable, no.
Banning cigarettes = easy to enforce.
Banning sugar in soft drinks = easy to enforce.
Limiting how many calories you can consume = how do you propose we do that? Do we even have the technology to track what someone eats? And do we carve out exceptions for athletes?
If there was a way to cap calories without surgically inserting trackers into everybody I'm sure you'd see a lot less opposition to your idea.
Whether something is possible to enforce seems like a sliding scale. We can totally imagine a world where a calorie cap is possible to enforce. In such a world, would it be reasonable?
I (sadly) completely disagree with this. There are still so many basic things they don't expose, and it feels like you're fighting an abstraction designed for a start-up that doesn't want to think about the complexities of payments at all. For example, you have to fight a battle to get the card IIN exposed to you. There's no way to see the electronicCommerceIndicator (ECI) for Wallet payments (it clearly has it, since it's shown in the dashboard if you dig deep enough, but it's kept from you). For their Direct Debit integration, they apply limits on the payment amounts you can initiate, but there's no way to actually see the current value of what these limits are. The same Direct Debit integration also doesn't let you customise the payment references used (GoCardless lets you do this to identify e.g. individual invoices on customer bank statements).
Some of the APIs clearly haven't been thought through - e.g. for disputes you can't programmatically retrieve the evidence submitted by the card issuer. Which means you can't build any sort of sensible custom integration for handling disputes. And besides, they don't even support pre-arbitration (which the card issuers know about and take advantage of frequently because they know their decisions outwith the card scheme chargeback guidelines cannot be challenged effectively).
Their Google Wallet integration is worse that Braintree's and doesn't support the web-based flow.
There's not nearly enough visibility when things go wrong, particularly with their 3DS integration (which was failing for Samsung Internet browser users for us, and we had to fight to get looked at - nothing ever got published on the status page despite the fact this significantly affected your chances of securing liability shift) and you have to escalate via an account manager to get any sort of useful support case response.
One of the first things I did when I was involved in the set-up of online support ticket system for a GB rail retailer was https://xkcd.com/806/ compliance. If the support request body contains the phrase "Shibboleet" the ticket will be assigned to an engineer.
Equally it's not hard to teach front-line when to escalate, and ensure L2 and beyond are approachable. Even better if L2/L3 can keep half an eye on tickets that come in for anything that looks particularly interesting.
> One of the first things I did when I was involved in the set-up of online support ticket system for a GB rail retailer was https://xkcd.com/806/ compliance. If the support request body contains the phrase "Shibboleet" the ticket will be assigned to an engineer.
I get the feeling you wouldn't joke about this. I can't believe how amazing this is LOL. I /think/ I know which retailer...good to know!
> Equally it's not hard to teach front-line when to escalate, and ensure L2 and beyond are approachable. Even better if L2/L3 can keep half an eye on tickets that come in for anything that looks particularly interesting.
Right!? I did L2/L3 support many moons ago and it was very much my job to keep an eye on PFYs to ensure they weren't dismissing interesting tickets.
These green percentage points at the bottom left show how many of the Web audience (IDK by what measurements) runs a browser supporting this feature. A ton of them are even below 50%.
So I suppose it's not "modern CSS", but more like "latest Chrome CSS". Best viewed in Internet Explorer 5.
I've found it to happen much more frequently than that, unfortunately. Usually it's because the modal is two DOM elements - a backdrop, that fades out the rest of the content and sits on top of it/prevents interaction; and the actual consent modal. Websites then use various mechanisms to prevent scrolling. uBlock is often only removing the actual dialog, so you end up with a page you can't scroll up or down and can't interact with.
If you're going to turn the filters on, it's worth being aware of this because it's far from flawless.
reply