MrMoo posted:

something different on sorting,

https://www.youtube.com/watch?v=sYd_-pAfbBw&t=179s

MALE SHOEGAZE posted:

at my startup our architecture is microservices and a message queue.

each microservice has its own mongo database, because this reduces coupling. allowing the services to access the same database would increase coupling, so if one service needs access to data in another service, the originating service will just dump the entire collection into the pipeline, and the consuming service will write out all of the entries into its own database.

whenever an entity in the database is updated, the responsible service will emit an update event, and dump the entire object into the pipeline. consuming services will then write it to their own db, taking extreme care to update any and all data associations (a traditional DB would of course enforce these relationships for you, but it's no loss because keeping data in sync is a totally trivial problem compared to coupling, which is the worst problem).

the architects of this system did not concern themselves with concurrency, because data races are trivial compared to coupling. we've simply forced each consumer to run on a single thread, because concurrency issues are difficult to solve and we have more important problems such as reducing the amount of coupling in our system.

naturally, this system contains json entities that can be over 1mb compressed. if a user updates a single field on one of these entities, the entire 1mb model will get dumped into the queue. if they update the model twice (or 100 times) it will get dumped into the queue each time. this in no way overwhelms the system.

a few months back, i introduced an RPC mechanism so that we could at least make synchronous calls between services in response to user events. today my lead informed me that we're going to deprecate the RPC system because it increases coupling.

this is how you architect a system with 12 microservices that cannot handle more than 4 or 5 concurrent users before falling over. Fortunately, since everything is so decoupled, the system at least maintains the appearance of working.

NihilCredo posted:

tfvc is simpler. a LOT simpler.

if you used git, it will be trivial for you to learn tfvc. all the history is on the server, and only on the server. branches are basically just folders with a history - they're full, immutable, indepedent copies of all the files they contain. checking out is just downloading a folder (or a specific revision of one) from the server to your computer: after that, the only thing tfvc does locally on your computer is keeping track that c:\myproject\butt corresponds to $/company/software/projects/gluteus on the server

shelvesets are a glorifed 'let's zip up my temporary changes, give them a name, and save them on the server'. they're used much more often than branches because, as mentioned, each branch is a full copy of the project so it's expensive to create and cumbersome to switch.

if you did anything more than the most basic stuff in git, you'll probably run into tfvc limitations. like, want to unshelve your shelveset into a different branch than the one you were working on? you have to unshelve + commit to the original branch, merge to the new branch, then revert the commit on the original. if other things changed in the original branch since you made that shelveset, tough luck. in theory there's a 'power tools' command line utility that lets you unshelve to another branch, but it's never worked for me, and I always resorted to copying files over by hand and checking the diff

tl;dr: you will probably be annoyed. you might be frustrated. you almost certainly won't be confused.

Pie Colony posted:

why would you not recommend? harder to version control i guess?

InfrastructureWeek posted:

Spoiler alert: you will regret this lol

Sapozhnik posted:

i'll also regret being out of work because we didn't ship a product before the money people lost patience

life is full of regrets

tef posted:

swedish collation by default

akadajet posted:

no, because twitter lets you know if your tweets are too long

Shaggar posted:

I just need something to store like 5 columns worth of data in a reliable, shared way and I didn't want to spin up a sql server for it.

Soricidus posted:

given that all programmers are poo poo, we should favor idioms that make the bugs they will inevitably write harder to exploit

John Big Booty posted:

tef posted:

lol it's totally a thing

John Big Booty posted:

Lots of times.

LinYutang posted:

generating javascript through Java string concatenation is extremely my poo poo

motedek posted:

i can't understand why anyone consuming data chooses to use a store that guarantees exactly nothing about what's in a record. projecting our collections (which were being used as de facto tables) into real tables was the only way to see all the nulls where different records used slightly different element names.

feedmegin posted:

Edge is specifically a new from the ground up rewrite which is why they also ship IE with Windows 10 for compatibility.

HoboMan posted:

just managed to take 3000 line sql query no one ever wanted to look at that is central to how our poo poo works and make it go from 15 second run time to sub 1 second.
guess how? if you guessed removing code where it was filling a temp table with a full copy of one of the largest tables in our database you win

cinci zoo sniper posted:

im not sure what you mean by defining type hierarchy. in general, i have a fairly good idea about possible abnormalities in the dataset, which is why i posted that isintance(x, dict) example earlier, since in this garbage i am forced to work with:

1) a value is always a string
2) a missing value is a 0-length string
3) a variable may be randomly placed in a dictionary containing just it (cause by some json (or mongo?) type thing (?extended types? i think?)
4) a collection of variables (json array?) is a dictionary
5) if there is just a single matching collection, there is a dictionary
6) if multiple collections match the record, they are contained in a list
7) if there are no collections matching the record, there is an empty list
8) a collection may randomly be missing one or more variables/sub-collections in it
9) a collection "tree stub" (?node?) may be missing as such

and so i have bunch of static methods covering each problematic variable where in each i have hardcoded substructure path housed inside at most 3 levels deep nested if condition tree to account for the mix of the factors above specific to data subset im extracting

hence the earlier question, if doing if isinstance, if foo in bar, etc - given known variability of the situation and having no way to affect it - is not inferior in some way to try-cath patterns or equivalent

now if you want actually embarassing stuff, let me tell you how i zip bunch of lists, sort by sub value, and then unzip them before passing further since i need homgeneous lists as final outputs

hackbunny posted:

Sapozhnik posted:

still paralyzed by indecision lol

i've done a complete and utter 180 on the file extension thing in the space of like 2hrs because there's a whole bunch of poo poo like jsx or es2015 or type annotations that you can mix and match into your toolchain and you're not going to stick all those things into the file extension

flow is also strictly just a type checker. there is a completely separate babel plugin that just strips out all the type annotations without checking them. and you slot that in amongst all the other babel plugins that implement jsx, transpile es2017 down to es5, do the css import magic, etc etc. this feels very right on a fundamental level.

typescript is a transpiler, and you then feed its output into another transpiler (babel). ts has a lot of overlap with what babel does but babel is a lot more powerful. this seems strictly worse than the way that flow does its thing and it bugs the crap out of me.

e: oh and i got it to compile and something went wrong at runtime but it spit out a backtrace showing the typescript-transpiled code instead of my typescript code. naaaa gently caress this, flow it is. i'll hold my nose and deal with atom i guess. urgh.