The idea is nice and needed. However maybe the spec is a bit elaborate for me to adopt it immediately. I've been rolling my own for some time at some clients, for our kafkaesque/event sourcing patterns.
However what I used there was simple http stream/json stream like this:
- No start of [] but JSON newline entries a new line is an new entry
- Using Anything as an id (we've been using redis XSTREAMS as lightweight kafka concepts, just 64bit integers)
- have an type as an event, and versioning is just done by upgrading the type, ugly, but easy.
- We'er considering using SSE at this moment
Compaction is not something that I would do in the protocol I think I would just expose another version of it on a different url I think or put it in a different spec.
Hmm for me a course did wonders really. It really allowed me to better express my own needs and feelings and dial in the feelings of others.
What described above I've seen happen, but mostly with beginners or people that use this new found ideas as agenda but without actually connecting with the other, expecting miracles or use NVC as a tool for policing. Or people that were already manipulative in the first place, but now just try to use NVC.
It can also come off as manipulative in an already unhealthy situation, where the relationship consists of so much mistrust that bringing anything new to the table is frowned upon and already met with suspicion.
My personal take away from it was to ensure that I prevent destructive communication and prevent blame using words things like "You should have" because they don't give the other tools to work with and actually address the problem at hand. For me the bottom line of the book was that us expressing our emotions and needs to allow the other, if willing, to actually address the problem at hand. It also made me see that sometimes effective communication was blocked because I had to deal with my own things first.
Communication, empathy, and time to actually listen, is something that unfortunately in my culture isn't thought as a core skill.
Pretty awesome project really! As a sidenote: A bunch of the ML training and edge deployment magic is done via https://edgeimpulse.com which seems to make it much more accessible to build such a thing.
> The depth maps we currently generate come from our hardware and software prototypes. And yes, we’re already at incredibly high levels. That’s because our “deep-learning algorithms” learn from all small errors and inaccuracies.
I like it that they quote deep learning algorithms
Its almost like applying DDD bounded contexts after the fact.Breaking up your apps in their boundaries and moving them out on the storage level. I do have some questions though:
1. wonder what happens on the edge of the boundaries when a table does need data from another domain. And what if that domain/cluster is down?
2. How do they physically connect to the cluster? A seperate db connection?
Ah nice to hear from a rancher employee <3. Ah yeah, I totally understand the move, no blame there. But cattle was just amazing, it was easy and elegant!
There is no mention on LXC/jails which is ofcourse the biggest inspiration for docker, if I am not mistaken it also used lxc under the hood. That was already a good'ish product and but hard to configure and not for the mainstream at the time. Docker introduced AUFS and downloading of images which was added. I always saw docker as a properly marketed nicely ribboned lxc but mediocre implemented since they removed a lot of options at that time that were super useful like cpu limiting etc from std lxc.
I think docker itself had plenty of time to innovate. They could have solved the problem long before mainstream got a hold of kubernetes. They just didn't solve the actual problems users where having at that time, which was container orchestration across multiple servers. They went very very deep with a lot of drivers and API changes and what not. If I am not mistaken docker-compose wasn't even a part of docker first before it got bundled, someone else was solving docker's same-server orchestration problems.
Kubernetes is for a lot of organisations pretty difficult and way too much for a start. We used rancher for solving our problems which did a fine job, rancher got a worse when they made the move to Kubernetes.
In the beginning they (docker) also removed a lot of options like cpu throttling and configuration and such that LXC had from the start. They also had their own version (a shim) of pid 1, some point at the time. And other things that made it a little painful to properly containerise. I was often very frustrated by docker and fell back on lxc.
There was also something with the management of docker images like pruning and cleaning and other of much needed functionality that just didn't get included.
Also something with the container registries which I a this point can't remember (maybe deleting images or authentication out of the box or something that made it hard to host yourself).
Anyway I think it's failed because it failed to listen to its users and act upon them. They really had a lot of chances I think. I think they just made some wrong business decisions. I always felt they had a strong technical CTO that really was deep on the product but not on the whole pipeline from dev->x->prod workflows.
Yes excited for this. I do believe having yarn introduced was the exact push NPM needed in order to tidy up their consistent installs game at that time. Hope these additions will make the ecosystem better.
Its interesting to see how technology sometimes drives away old professions, reminds me of this documentary https://vimeo.com/66507747 about the last ice man in Ecuador.
Serious question: We talk always about companies like they are are organisms and not run by people making decisions. I see texts referring to group, company, people. Who's making the decisions and why don't we address them by name? Would this not make them more accountable if we did?
I work with XML quite a lot for connecting legacy but also 'modern' systems, and there are some good parts and some absolutely horrible parts, let me go on a rant for a little.
I classify them as sane XML ideas and some as complete utter garbage.
Good parts
- Schemas for documents - If you have a single schema file, and a single XML to do validation its KINDA nice. If you limit yourself to a basic set of XSD types its okay ish.
- The general idea have XSD's express document structure and have a standard for it is kinda nice.
Bad parts
- people go absolutely bonkers with schemas, have schemas in schemas, do complicated stuff that can hardly be expressed in modern type systems, and even harder to generate code for. Things like PEPPOL or UBL are extreme horrible overly complex solutions, and you need an army of devs that have the patience to implement it properly.
As a result, everybody does the bare minimum and gets their own flavour and you're still making per supplier code since everyone just tries to make it work. Our code base has a ton of 'fixers' per supplier to convert their iffy files to something sane. We started by asking them to fix their files but in the end it was just waaaaaay faster if we dealt with it, because the complexity of truly understanding XSD's is quite complicated.
- The a part of the standards community, feels more like schema designers than actually implementers. It feels like whenever a committee designs a standard they're like "WE'RE DONE!" without actually implementing it themselves across languages and see how hard actually is to generate something valid. These organisations are head-acheinducing money sinks where there bad schema ideas trickle down.
- It can basically do too much, what you want is a tiny expression of your types.
- JSON Interopability: You can't just convert JSON to XML without schema knowledge. In XML this can `<user><name></name></user>` can either be an item in an array [], or a hash. You need to know the schema to understand how to deserialise or generate properly, you can't cheat.
- Its super verbose, and hard to read. When you're staring at 200 lines of XML, you're brain has to parse all the verbose namespaces and what not in order to pick out the data.
I also deal with +1GB XML files and then the tooling to support large files grows thin. And you resolve to SAX parsing and emitting nodes. It aint fun. In the end I had to write a lot of tools myself to make it manageable to work with many documents.
Anyway thanks for reading this far, I really needed to vent hahaha