fsajkdnjk

The title should be: "Insights is a tool to visually explore a PostgreSQL database"

sound great, doesn't work. if it would work, we would have perfect translations for spoken languages already. and google(translate) with it's massive computing, financial and brain power still hasn't figured it out.

i think that if you get the hardware info you will be able to find out some virtual pieces listed in there.

none. tracking makes you into a cattle. a dumb product to profit off of.

miss? no, not really. but slack ain't it either.

nowadays, as golang dev, i don't even know how DRY looks like :D

what I've learnt throughout many years of coding is that purest mantra one should follow is YAGNI. devs think like devs and strive for perfect code. but that goes directly against the business. the majority of the entire world is being run on really bad code. but that bad code works. and that is what is important.

in a way, you should treat things like blackboxes with strict interfaces. no one should care how the box works, as long as its interface works like it is supposed to.

PS: the dangers of DRY are introduction of deep dependencies that might, and probably will, bite you in the ass along the way. DRY should be used only for libraries, not for business logic - ever.

the best thing you can do is hire a good accountant and go through their books.

it used to go to my "fuck you" pile of cash but now i put it all into stock market. cash is just dead value that depreciates with inflation. i keep some for bad times but the rest is in equities.

the stored events are called event but they are actually envelopes. the true changes("event"), or payload of the envelope, is stored as serialized field. the envelope holds metadata like dates, domain, aggregate type and id, event name, correlation, causation, user/account, event schema version(this is what you are asking about) and so on. i am using protocol buffers so they are backwards compatible and event schema can evolve in time. but you can use any type of format as long as you keep the schema version within the envelope and only add new fields to the objects.

then, when you are parsing the events(hydrating or replaying) you just check the schema version in the envelope and handle the changes/payload accordingly.

it's actually very trivial once you put it all together.

assuming no smartphone in this scenario, every time you visit any o their services you are being tracked via ip and headers you sent(referrer for example). this way they can build a profile, even if they do not have your personal details. you think you are "safe" if you do not use their services but 99% of websites use their google analytics, cdn or social widgets/sharing buttons... which allows them to track you. so the only way to avoid this breach of privacy is to keep your hosts file updated and never let your browser access any of their websites. i would also be concerned with their dns over http now.

facebook is the same but due to its nature it does it only via its social sharing widgets that people put on their websites and the embedded comments and things like that.

google's cdn is the most dangerous of these things.

you are 100% correct. one day i found my 5 months old comments on youtube, which i deleted. i expect someone had restored a backup due to some kind of failure. so yeah, 100% breach of GDPR right there. but an individual, that is the product here, cannot do shit about it, that's just a illusion. only government have the power to actually fix this mess.

i have been working with eventsourcing for the past few years and a design i have implemented in the repositories(db) lately is to have one table for events and one table for snapshots(ie. the objects in the current state in serialized form). then, depending on the needs of the application(ie. what queries will be run) I will create tables that will serve as pure indices by which I can then lookup the aggregates(object) I need. This gives me incredible flexibility and I do not need to bother with complex schema at all. I use event reactors within transaction context(imagine pre-save trigger per object) to fill these tables with data(or remove data). and from now on i think this is the way to go for me for anything. having your sql schema matching your objects/entities is very restricting and not flexible for future development. with this approach i have the full data available(snapshots) so i don't need to hydrate each aggregate from the event stream and i also have the ability to filter the aggregates as i need and also have highly optimized schema for any query i desire. when something changed in the future, i can simply play through the entire event stream and fill in new indices or whatever is needed. machines are fast these days so storing the entire object as snapshot in serialized form is nothing and it beats having to load tens of fields/columns and parse it into objects manually.

minds.com, bitchute.com :)