LAST DAY at the client who is probably sending you those "real people" text messages from the democrats. (say you've already voted and that info makes its way up to the national dnc database btw and they should stop texting from anyone affiliated)
Pro: going from 1k regs/s to 140k reqs/s in a month is fun and its wild how even when you write what I would call "bad practices" elixir just chugs along.
Cons: realizing you're effectively helping spam, even if its for a "good cause"
Things I've Learned:
- there is a war happening over clean non-spam associated phone numbers in the US. And maintaining ownership over good ones is a huge task at these scales
- please please please dont' do n+1 queries. ecto explicitly makes this hard and yet people do it, your app probaly won't suffer like a rails app would but its wasteful
- LiveView is quickly becoming my default platform, its actually very good.
- redux/ember-store/altjs/mobx all of the central js "stores" are probably a mistake. I can see an argument for them if you use a strong type system everywhere, like Elm or maybe typescript with no exceptions, but without the type system you have *no clue* what state you actually depend on. This compound issues on the backend when you try and remove n+1 from above.
@peregrine the "store" can be used to good effect, but only when proper discipline is applied. which is the problem lol
trying to keep store usage in check is like herding a bunch of cats. its obviously better than forwarding events up through a pile of components, but then arranging state logically within the component tree goes out the door for some reason. NO DO BOTH
putting state or behavior in the store that isn't actually global. which is to say, state and behavior that is not needed by multiple independent component trees.
components can and should have state, not all state needs to go through the store. a lot of application state could never touch the store and it would be fine.
@xj9 @peregrine i used to think that, but I am starting to think that it isn’t very complex, that over time, develooers seem to have cumulatively gotten stupider over time and made things way more complex than they need to be.
it is very complex to get a fast loading responsive UI to load and perform well in a browser.
much less complex to just make a plain old website, which more times than not lately, was probably all that was needed.
@morgan @xj9 @peregrine there’s this insanely great peice of software called Quartz Composer that Apple included with fheir dev tools. (sadly apple has abandoned it)
some engineers at Facebook discovered it and proceeded to base their entire company software architecture around it/modelled after it. Quartz composer is an FRP system
@morgan @xj9 @peregrine React is based around the concepts of FRP. sadly, it’s gotten a ffew important aspects of FRP really really wrong, and consequently given a lot of people really wrong ideas about FRP.
but anyhow, the essence of FRP is to abandon the concept of “variables” in programming, that is, slots of memory that you set to some value- and replace them all with Signals- a named continuous stream of values over time.
@morgan @xj9 @peregrine so, in quartz composer you had a livecoding environment- that is, the program is running while you edit it. but because the language doesn’t permit mutation or persistent state, it’s totally safe to do this: the running program is actually running 60 times per second. changes are reflected instantly on screen.
@morgan @xj9 @peregrine
something like redux, is actually a mathematical trick to simulate persistent state- if you can feedback an output value to input, state is just past state + present input, which you can achieve with a “reduce” function.
everything else in the system works by source/sink/filter: a patch (function) is either an impure input, an impure side effect, or a transformation of a signal- borrowing terms from electronics/analog synthesis
@xj9 @peregrine like. say you have a big old grid of data, and you want to make it easy to filter and sort by various fields. and there’s a lot of data, so you kinda need to asyncronously load and unload data as it’s requested- you need an api to dynamically request peices, you need caching strategy so you don’t crash the server.
it’s also like 10 components you can just buy and never have to build any of that.
but the store is a cache, and often global. If your components depend on the store and someone else putting the data in the store and you change it without a strong type system or tests your site is now broken. (this is project had hundreds of components)
@lain ideally no :P but its all relative
Merveilles is a community project aimed at the establishment of new ways of speaking, seeing and organizing information — A culture that seeks augmentation through the arts of engineering and design. A warm welcome to any like-minded people who feel these ideals resonate with them.