People tend to underestimate how cold it gets in the interior of countries generally seen as the "sunny Mediterranean" - from Croatia, Montenegro, Albania and even Greece.
And Spain. Bring these "sunny Spain lovers" to North/Inner Spain in Winter. Watch them running away as if it were some kind of weird disease.
Also, spotting the typical tourist climbing the Picos de Europa range in sandals is not weird. What's weird if he/she makes it alive... or without frozen fingers or toes.
Yes, I've been searching for a long time for a good solution to allow non-coding people to visually design JSON Schemas. The closest thing I found is the schema editor in the amazing Stoplight service, but that is sadly not open source.
Heck, I'm a coder and I get lost when just dealing with the raw JSON Schema.
It's not a problem for a dozen properties, but we have several hundreds in our larger schemas, even accounting for them being fairly normalized w.r.t. types. And five or more levels of nesting turns into an effective ten plus levels in the schema.
One underutilised feature of JSON Schema is referencing external schemas and reusing them in multiple places, rather than copying them over and over again. The main hurdle to a better use of this feature is the lack of a good standard for schema repositories; I've been working on addressing this, but it's difficult to find the time. :/
> One underutilised feature of JSON Schema is referencing external schemas and reusing them in multiple places
Yeah, though while it does make each subschema somewhat more readable and contained, you still don't get a good overview. If you're reading the spec for a given object, do you don't easily see where it's being used in the schema.
For now I've just supplied the JSON Schema as a self-contained thing, and deferred other parties to the XSD to get an overview. The self-contained makes it trivial to load into a validator and such.
So while it helps for knowing what to fill into that exact object, it doesn't help for getting a feel for the overall schema. This is where the visual view of tools such as XMLSpy really helps.
> lack of a good standard for schema repositories
Interesting, do you have something public to show? For our large ones I feel they'd be entirely custom anyway, but perhaps I can see standard sub-schemas useful for other tasks. Would be interesting to have a look.
True, when focusing only on the schemas as code. But good tooling could provide links and similar.
> do you have something public to show
Just a very early PoC [0]. I'm slowly working my way through a very long to-do list of improvements, but I'm lacking time and resources to do it more efficiently.
I suspect they meant Nvidia, not Netflix; after all, the letters in MANGA are exactly the initials of the companies listed in the post they were replying to.
The N was really Netflix originally when it was the poster child for AWS consumption before NVIDEA/AI was even in the conversation. But, yes, "Big Tech" is probably the best term these days to avoid debates about whether this company or that company really belongs in the category--especially given that certain companies have done very well in terms of stock relative to the the historical FAANGs.
FANG (notice the missing A) was always a meaningless term. Cramer initially left Apple off and it was already the most valuable company, Microsoft was already in the top 5 most valuable and Netflix was t really that valuable then.
To be fair, any (immutable) data structure that includes the creation timestamp can be a queue. It might not be a good queue, but it can be used as one.
On this note... has anyone here used object storage directly as a queue? How did it go?
You can make a bucket immutable, and entries have timestamps. I don't think any cloud provider makes claims about the accuracy or monoatomicity of these timestamps, so you would merely get an ordering, not necessarily the ordering in which things truly occurred. But I have use cases where that is fine.
I believe with a clever naming scheme and cooperating clients it could be made to work.
Once used object storage as queue, you can implement queue semantic at the application level, with one object per entry.
But the application was fairly low volume in Data and usage, So eventual consistency and capacity was not an issue. And yes timestamp monotonicity is not guaranteed when multiple client upload at the same time so unique id was given to each client at startup and used for to add guarantee of entries name.
Metadata and prefix were used to indicate state of object during processing.
Not ideal, but it was cheaper that a DB or a dedicated MQ.
The application did not last, but would try again the approach if adapted to stuation.
The application I'm interested in is a log-based artifact registry. Volume would be very low. Much more important is the immutability and durability of the log.
I was thinking that writes could be indexed/prefixed into timestamp buckets according to the clients local time. This can't be trusted, of course. But the application consumers could detect and reject any writes whose upload timestamp exceeds a fixed delta from the timestamp bucket it was uploaded to. That allows for arbitrary seeking to any point on the log.
The key question I see here is: how would a vehicle be tracked?
There are two options:
1. A dongle with GPS, mobile connectivity and some other features would be installed to all vehicles. This makes it easy to implement the system, but would be a logistical nightmare.
2. The government could receive information directly from the manufacturers, but that a) can be a privacy nightmare, b) would work only on cars manufactured after 2016 or so, and c) is insanely complex to implement, due to differences and incompleteness of various manufacturer's API implementations (source: I worked on one such system).
One solution that comes to mind is to use the same technology that already exists for traffic violations: when a vehicle enters or leaves the motorway it would get its licence plate scanned, and a fee would be applied to that vehicle's account. The owner can then be charged in a number of different ways - immediately, or periodically, or after a certain threshold was reached - whichever is the most practical.
Fuel duty works out at about 5p/mile. Slightly more for thirstier vehicles, slightly less for lighter vehicles.
There is zero need to implement anything for petrol or diesel vehicles, which nicely eliminates the "pre-2016" problem (How many 10 year old electric vehicles are there? Not enough to worry about). I'd be inclined to provide a government API, and require the manufacturers to provide the data in a specified format. Make it part of type approval for use on the UK roads.
Not impossible, nor should a VIN + Mileage number be particularly risky for privacy concerns - the number should be pushed regularly, to prevent wind-back tricks.
15p/mile has got to be a joke though. That'd be the equivalent of setting fuel duty to £1.50/litre - it would immediately shag what's left of the economy.
> I'd be inclined to provide a government API, and require the manufacturers to provide the data in a specified format. Make it part of type approval for use on the UK roads.
Knowing how this industry works, good luck making something like this a reality, especially in a single country. Even if the EU tried enforcing something like that (with the UK piggybacking on it), it is still a small portion of the market.
Sadly, this is not a technical problem, but a political one. That said, I agree with you, and we can always dream.
True, but that is a general mileage - it doesn't tell you where it was made. I.e. how much of it was made abroad, how much was on local roads and how much on motorways etc.
People tend to underestimate how cold it gets in the interior of countries generally seen as the "sunny Mediterranean" - from Croatia, Montenegro, Albania and even Greece.
reply