Follow

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"

· · Web · 3 · 0 · 2

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.

Show thread

- 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.

Show thread

@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

@xj9 @peregrine not sure i follow- what’s an example of bad store usage?

@zens @peregrine

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 right, i guess that always baffled me about redux- or at least conversations from people using it: why would avoiding that take discipline? doesn’t the app have a design? this makes it kinda sound like it’s being made up as you go along.

@zens @peregrine there's also the issue of orgs not knowing what they want or need multiplied by their unwillingness to hire experienced (ergo expensive) talent. so you end up with novices building stuff with no plan.

@zens @peregrine to be fair, building a complex user interface is not an easy thing to do. web at least has some interesting ways to approach the problem.

i would love a native elm omg

@xj9 @peregrine it seems to be getting more complex every year, under the guise of making it “simpler”

@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.

@xj9 @peregrine not to pick on anyone in particular. i am as guilty of this as anyone

@zens @peregrine

depends on the interface. some are too complex to do with plain html.

@zens @peregrine

not that i'm defending the complexity of web. it is too complex, i just happen to like the FRP approach to making user interfaces.

@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

Show more

@xj9 @peregrine this is true, but in many of those kinds of cases that i have encountered, there’s no actual purpose to the complexity- it’s just how someone decided to design it.

@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.
that’s complex.
it’s also like 10 components you can just buy and never have to build any of that.

@xj9 @peregrine the most complex things i have needed to build was that time that light boxes and video players were trendy at the same time so i kept getting asked to put videos inside of lightboxes and that just never works very well at all.

@xj9 @zens @peregrine Where do you put it if you want to persist and don't use the store? I'm thinking specifically vue/vuex. I put some stuff in LocalForage but I put a lot of session state inside the store because it's easy and because I get the benefits of time-travel.
@xj9 @peregrine @zens Incidentally I skipped using Elm for personal projects as it seemed like you're very
much at the mercy of the documentation, which I'm told is incomplete for the latest version.

@Moon @peregrine @zens

i guess that's true. also true for almost everything i work with so i guess it didn't seem unusual.

@xj9 @peregrine @zens I've just become old and tired and don't have the energy to learn a not-well-documented system (he said, as he warmed up his urbit)

@Moon @xj9 @zens meh I'm not gonna touch urbit.

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)

@Moon @peregrine @zens

i would consider persistent state a kind of global state, since its shared between multiple systems (some component tree and localStorage).

Sign in to participate in the conversation
Merveilles

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.