Powerful Two-Hander posted:

Shinku ABOOKEN posted:

what is so extreme about systemd? every service that systemd provides you have to do anyways so you might as well integrate it in your service manager and get it over with. the argument about it being single point of failure is something I don't buy since for such a critical component you better have a single point of failure and focus your attention there instead of a billion points of failure.

MrMoo posted:

Usually with Systemd cruft doesn’t stay around too long.

Beamed posted:

.net core providing one ootb so that you don't have to put up with nonsense was a real smart move

abraham linksys posted:

the only js framework i know of that has embraced DI as a concept was angular and, well, that didn't go super well on a number of fronts

with react/redux a lot of the time the patterns actually lend themselves pretty well to not needing mocking since there's usually some layer of indirection you can test instead (testing that an action is dispatched instead of mocking out a method on an object). a lot of times stuff that would be provided by a DI container can live in some top level component and get accessed through context, for things like api clients and whatnot, which... i dunno that's basically DI, if you're coming from the perspective of "DI is basically just passing dependencies as arguments to things"

Arcsech posted:

and drat near impossible to get rid of if you fall into the trap of relying on them too hard

the codebase at work has been trying to rip out guice for literal years after realizing how bad it is. 90% of our use has been replaced by explicitly constructing things, which works a lot better.

piratepilates posted:

at work for testing react components that are connected to the redux store, I've just been exporting the unconnected component to be tested with, and exporting the connected components as the default export to be used in the app.

limit the scope of the props you're passing down from the global store, and add them to proptypes, and testing redux-connected components hasn't been bad for us, we just pass in the props that would be passed down from the `mapStateToProps` function and don't worry about simulating the global state.


I haven't used angular since the initial version (before they changed the name from AngularJS to Angular, and rewrote the whole codebase) but christ what a shitshow of complexity and unnecessary new terms that was.

then react came out and it was so much simpler and straightforward (but also powerful enough to run one of the most trafficked front-page heavy websites in the world)

gonadic io posted:

any advice for breaking out of the classic loop of: doing tech debt informally, so tickets take longer, and management won't dedicate time to tech debt due to tickets always already being behind

gonadic io posted:

I mean that's the successful strategy I have used for previous companies I'm trying to avoid it this time I like this company but it's got the classic startup-no-more growing pains

piratepilates posted:

redux is one of the react cases where it got super hyped up for some reason, and everyone thought it should be used everywhere always at all times for everything.

as a result you see people race to use it for everything for no good reason, like storing every piece of their application's component-local state in it, and never using `setState` or `useState`.

it's meant for one thing: global shared state across a react application. it does it pretty decently (but with admittedly really lovely boilerplate/syntax). if you don't need to share global state between two components that otherwise have nothing to do with each other (i.e. no close common parent), then it's not needed. even if you have a need for some global state, if you can satisfy that requirement with making separate api calls, that's probably a much better approach for as long as you can reasonably do it.

abraham linksys posted:

to be fair, local state and async behavior was difficult to unit test in react for a really long time. was hard to write a test like "click this button that will trigger a mocked async api call and check to make sure it updates to show a success state" or something, compared to testing "this async action creator will dispatch a success action, this reducer will set the didSucceed flag in redux state, this mapStateToProps() will pass didSucceed from the store to the wrapped component, and this component will show a success state when passed didSucceed=true."

newer, better test libraries and hooks might have fixed this to an extent? i just remember pre-redux react having to do a lotta setTimeout(fn, 0) hackery to get my tests to run in order with async behavior

abraham linksys posted:

we're moving off enzyme to react-testing-library soon, probably, though i couldn't really tell you exactly why

i did a couple minutes of googling and found this article that describes the problem with async testing that i've faced in the past, but also indicates that react-testing-library has a waitFor() util that solves this problem, neat: https://www.benmvp.com/blog/asynchronous-testing-with-enzyme-react-jest/

gonadic io posted:

please read my latest medium article: lkdsjflsdjlj sdljfl dsjf l;sdjk; flkas;'l d';pakf; lsdjk; fksa';d/ kas'kf,

Soricidus posted:

you must be disappointed a lot

Symbolic Butt posted:

"initial commit" is fine because the README of your project at that point serves as a detailed "commit message" describing what's going on

Soricidus posted:

you must be disappointed a lot

Illusive gently caress Man posted:

my recent pet peeve is when a function starts out clean. like it has one or two input parameters and returns a value. nice

later, someone adds another parameter like like "bool do_slightly_different_thing" or "also_do_other_thing." mayyybe this is reasonable.

repeat 1-3 more times. now the function is 10x harder to understand and annoying to refactor because it's called in multiple places for only tangentially related purposes.

is there a pithy phrase for this problem?

Boiled Water posted:

i tried but it ruined my ubuntu install

CRIP EATIN BREAD posted:

that domain is hilarious and don't you deny it

jesus WEP posted:

reader mode is such a good instakill for anti-adblock bullshit

Powerful Two-Hander posted:

"this code was generated by a tool" lol you got that right visual studio

Powerful Two-Hander posted:

this one is funny because it goes through loads and loads of problems caused by chasing an architecture based on it being hip rather than practical, but instead of providing and alternative s or solutions just goes 'guess we better just keep trying lol!:

the statement of "if you use a single database you introduce problems like accidentally dropping an index or being unable to determine what is touching a table" is not some incredible problem you can't solve, it's a problem you created yourself by being an idiot and doing a classic webdev "a database is a mysterious filing cabinet key value store we have no ability to influence".

so of course the solution is some bullshit involving various aws services